Refactoring is the one track whose result cannot be shown in a demo. On the surface nothing changes. What changes is the cost of everything that comes next: a new feature once again costs what it should, and a fix in one place stops breaking another.
This is a track from the corporate growth block. It is added once the product is live and moving from MVP to MMP and MLP, and code written to test a hypothesis quickly now has to survive years of development. The guide price for the track in the Ingello price list is $4,700.
What technical debt looks like to the business
Owners rarely see the code, but they see the consequences clearly. Estimates for similar tasks grow from quarter to quarter. After every release, bugs appear in places nobody touched. Developers ask to "rewrite everything first". Replacing a payment provider, CRM or AI vendor is estimated in months, because the external service is called directly from dozens of places.
When it pays off and when it does not
It pays off when changes in one place regularly break another, when a new feature costs noticeably more than a similar one did six months ago, and when a new developer takes weeks to get into the project. It does not pay off if the product is about to be shut down or the hypothesis has not been tested yet. In that case it is more honest to finish the code as it is and come back to it once it is clear the product will live.
What the work includes
The price list describes the track in two lines: improving code quality, and preparing for long-term support and scaling. In practice the work runs in this order:
- A map of problem areas: where changes most often cause bugs, where logic is duplicated, which modules nobody dares to touch.
- A safety net: tests on the scenarios that make the most money, written before anyone starts changing the code.
- Separation of responsibilities: business rules move into services, while controllers and templates stay thin.
- Decoupling dependencies: your own layer appears between the code and external services, and every call goes through it.
- Order in the data: poor relationships and fields are fixed through migrations, with a plan for moving data and rolling back.
- Clean-up: removing duplicates, dead code and libraries nobody uses.
- Shared coding standards and automated checks, so the order does not erode once the team leaves the project.
Each step is released on its own, and the system keeps working between steps. We do not offer refactoring that freezes the product for two months.
What you get
- Predictable estimates: similar tasks cost similar amounts again.
- Fewer bugs after releases in places that were not changed.
- The option to switch contractor, vendor or service without rewriting half the system.
- Code a new developer can get into in days rather than weeks.
- Readiness for growth in load and users without replacing the foundation.
How much it costs and what drives the price
The guide price is $4,700 for the track. Scope depends on the size of the codebase and on which areas matter to the business right now: rewriting everything is almost never necessary. Existing tests matter too: if there are none, part of the budget goes on a safety net before any changes.
If another team wrote the code, the first step is an audit: $800 for a written report or $2,400 with an early prototype of the change. It records problem areas, technical debt and risks, and only then is it clear which option is better value: stabilising the system, refactoring specific modules or designing a replacement.
Why it is risky without tests
Changing working code without a way to check it still works is a dangerous idea. That is why test automation usually goes alongside refactoring or immediately before it.
What breaks if you cut corners
- Every new feature costs more than the last, and the development budget goes on working around old decisions.
- The team becomes afraid to touch the code, and the product stops changing as the market does.
- Vendor dependence becomes a trap: prices and terms change, and leaving is expensive.
- Eventually the only option left is a rewrite from scratch, which costs many times more than timely clean-up.
An example from our practice
The most expensive dependency in an AI project is often not the model but its API. Once a dozen tools have learned to talk to one specific interface, switching vendors becomes a project lasting months. We solved this with a local gateway: it accepts requests in the old format, translates them for another provider and routes them between models. The code of the calling projects does not change by a single line, and two providers can run side by side with failover between them. Details are in the case study on the AI provider switch adapter.
We apply the same decoupling principle to payment systems, CRMs and any external service: one layer that every call goes through, instead of calls from every module.
Where to go next
Related tracks: server optimisation and documentation. The map of all stages is in the app development strategy. Our approach to system architecture is described on the Ingello Systems page.
In a free consultation, an Ingello architect will review where the code is holding back your product and propose an order of work that does not stop releases. Afterwards you receive a price and timeline estimate broken down by stage. Discuss the state of your codebase.
