Bringing an Existing Rails App Under Our Care
A repeatable process for taking over long-term maintenance and support of a Ruby on Rails application someone else built, whether that's a state or local government office, a HIPAA-covered practice, or any other business that needs it to keep running.
A lot of the Rails applications we take on weren’t built by us. They were built by a previous contractor, an in-house developer who’s since moved on, or a team that’s grown past what an aging codebase can support - and the application still needs to keep running securely for years to come. Bringing one of these applications under our care is different work from building something new, so we follow a specific process for it.
1. Due Diligence and Fit Determination
Before we take on an existing application, we ask a lot of questions about the codebase, the team, and what’s actually driving the need for a new maintenance partner. We’re quick to tell you if we’re not the right fit for a particular project rather than take on work we can’t do well.
2. Discuss Client Goals and History
Every application has a history - why it was built, who built it, and what’s changed about the business since. We talk through where the project has been and where you need it to go before we touch any code.
3. Pre-Project Code Review and Security Assessment
We review the application’s code and its security posture before doing anything else - the same discipline behind code review before a pen test. A security assessment on an application no one has looked at closely in years turns up a lot more once the code itself has been read carefully first.
4. Flag and Prioritize Deficiencies, Lay Out a Roadmap
That review turns into a prioritized list - security issues first, then maintenance debt like outdated dependencies and unpatched gems - and a roadmap for addressing them in order, so you know what’s happening and why before we start.
5. Containerize for Long-Term Support
Before we change anything, we containerize the application with Docker, or whatever technology fits its deployment, so local development, CI, and production run against the same known environment instead of drifting apart - the same approach behind the government agency case study on our testimonials page. Everything after this happens against that stable environment, not whatever the previous team happened to have running.
6. Write a Test Plan
With a stable environment in place, we write out a test plan for the application - starting immediately with smoke tests for any legacy code that has no coverage at all, so there’s a safety net before we touch it, then expanding into real coverage across the parts of the application most likely to break in production.
7. Implement Necessary Security and Development Changes
With a stable environment and a safety net of tests in place, we work through the roadmap, highest-priority fixes first, and can actually tell whether each change works before it ships.
8. Continuous Blue Team Processes
Onboarding ends with the application in a known, documented, tested state, but the work doesn’t stop there. We run continuous blue team processes after that: ongoing vulnerability management, patch cadence commitments, dependency updates, and regular review - the same ongoing maintenance and support we provide for every application in our care.
Ready to Bring Your Application Under Our Care?
If you’re maintaining a Rails application that’s outgrown its current support, get in touch or call us at 770-623-2059 - we’re happy to talk through fit before anything else.