Ruby on Rails development, upgrades and maintenance
New Rails applications, upgrades of old ones, and steady maintenance. Paul, who founded AL+, has built software for more than 12 years, mostly in Ruby on Rails, Elixir and PostgreSQL. We upgrade one version at a time with tests around each step, we test and review changes before release, and your application keeps serving customers while we work.
Rails work for new and existing products
A new Rails product starts with the users, the business workflow and what it takes to run. An existing application starts with understanding how it behaves today and what makes changes difficult.
We work on complete product changes, covering behavior, data, integrations, background jobs, tests and deployment. For a new subscription product, see SaaS development.
The project runs like every project we take on, with a written scope and one fixed price, a demo every week, and an experienced engineer reviewing every change. See how a project runs.
Taking over an application without losing the context
Before we promise features, we secure access to the source and the infrastructure, set up an environment we can reproduce, and find the release path. Then we read the data model, the critical workflows, the integrations and the tests that protect them today.
Our codebase takeover checklist lists what we check. The first review names the next safe change and the open questions that still affect an estimate.
Rails upgrades and modernization
Upgrading Ruby, Rails and gems can change how the application behaves, deploys and talks to other systems. We plan against your actual versions and their compatibility limits, with checks around the paths your customers rely on.
We stabilize the system first, then make bounded changes and verify each release. Replacing the whole product has to be justified by evidence and is never the starting assumption. See application modernization.
A review before a decision
You may need a focused review before deciding what to build or repair. We examine the codebase, the release process, performance problems and dependency risks, then explain the proposed work and its limits in writing.
We agree in advance what the review must answer and which systems we can access, and it has a fixed price. A review lowers risk, and it can't promise that every defect or security problem has been found.
Maintenance after the first change
New features, defect investigation, dependency updates, infrastructure and release checks are ongoing work. We agree responsibilities and access before something turns into an incident.
Our software maintenance service covers ongoing ownership. We work remotely, in English or Romanian.
Questions about Rails work
Our app is several Rails versions behind. Can you upgrade it?
Yes. We move one supported version at a time, deploy and check each step, and keep the application running throughout. The first review tells you how far behind it is and what blocks each step.
How long does a Rails upgrade take?
It depends on the gap between versions, the gems involved and how much of the app has tests. We give you a plan with the steps in order after the review, not before.
Can you work with our existing developers?
Yes. We agree who owns which part before we start, and every change goes through the same tests and review.
Will you rewrite it in another framework?
Not as a starting point. Most Rails applications that reach us are worth keeping and upgrading. A rewrite has to be justified by the evidence, as our repair-or-rewrite article explains.
Related thoughts
-
Codebase takeover checklist: what to inspect before accepting a system
A reusable checklist for taking over software from another developer, agency, or team: access, production, data, change safety, dependencies, security, knowledge, and cost. Use it before you agree to own the system.
-
Repair or rewrite?
A rewrite is a conclusion you reach after understanding a system, not a starting point. Most systems proposed for rewrite need an owner, a plan, and a few months of repair.
-
Maintenance is product work
Most of a product's life happens after launch. Treating maintenance as a cost to minimize is how software quietly degrades and how the best improvements never get made.
Tell us what your Rails application needs next
Tell us what the application does, who maintains it today, and what you need changed or fixed. Include the Ruby and Rails versions if you know them, and any deadline, such as an end of support.