Software maintenance and evolution
Software in production doesn't stand still: dependencies age, rules change, and the cost of altering anything grows. Maintenance here means keeping a system working and able to change — engineering work on the codebase, not infrastructure support or a helpdesk.
Who this is for
- The system works, but each new feature takes longer than the last.
- Whoever built it is no longer available.
- There are known defects nobody can reproduce safely.
- Dependencies are out of date and nobody wants to be the first to upgrade.
Problems we solve
A cost of change that only grows
When every alteration requires understanding the whole system, the estimate for any request goes up. It usually isn't the team's capability: it's the absence of clear boundaries between the parts, and that is recoverable.
Behavior nobody can explain
Errors that appear in production and don't reproduce locally are usually a lack of visibility, not a mystery. Logging, monitoring, and a reproducible way to run the system turn them into ordinary problems.
Dependencies frozen in time
The longer they go without updating, the riskier updating becomes — and waiting doesn't remove the risk. The path is upgrading in verifiable steps, starting where there's coverage or where the code is most isolated.
A system nobody knows
When the original team left, the knowledge stayed in the code and in nobody's head. Recovering it is concrete work: mapping what exists, where the rules live, and what is safe to touch — before promising a date.
What we do
- Technical diagnosis of the current system
- Fixing defects and inconsistent behavior
- Ongoing functional evolution
- Dependency upgrades
- Observability and deployment process
- Modernization in stages
How we work
Understand before estimating
Understanding the current state of a system comes before estimating time and scope: what it does, where the business rules live, and what is safe to change. That reading may conclude that the best path isn't with us, or that rewriting costs less than maintaining.
Stabilize before accelerating
First the system stops surprising people: the most frequent defects, visibility into what happens in production, and a reliable deployment path. Only after that does accelerating feature delivery make sense.
Modernization in stages
Replacing everything at once concentrates the risk at the worst possible moment. We prefer isolating one part, replacing it while the old behavior is still available, and repeating — even if the total takes longer.
Leave the system explainable
The goal isn't to create dependency on whoever maintains it. Decisions written down, a reproducible environment, and as little knowledge as possible living only in someone's head — including ours.
Where we work
Frequently asked questions
Can you take on a system built by another company?
Generally yes, provided there's access to the code, the environment, and the history. It starts with understanding the existing system, its dependencies, and where the risk is concentrated — without that, any timeline would be a guess.
Is it better to maintain or rewrite?
It depends where the problem is. If the architecture still supports what the business needs, maintaining and evolving usually costs far less. Rewriting is justified when the cost of each change already exceeds the cost of starting over — and even then, usually in stages rather than all at once.
How do you start modernizing a legacy system?
With whatever gives visibility: logging, monitoring, and tests around the most critical areas. With those in place the rest can change safely, instead of replacing everything and discovering the effects in production.
Let's look at your system
Tell us what it does, how long it's been in production, and what's blocking you today. We start by understanding the existing system, what needs to change, and where the main risks are.