The module nobody wants to touch any more, put right one step at a time
CODEPRESS's targeted refactoring puts right one area of the code that slows down every change, not the whole system: a scope agreed up front, in 3 to 6 weeks, from €6,000 depending on how wide that scope is. We write characterisation tests that pin down current behaviour first, then change it in small, reversible steps. You get the code in production, the test suite and a measured before and after.
from €6,0003–6 weeks
What targeted refactoring is for
There is always one part of the codebase the team has stopped touching willingly: every change there takes three times as long as it should, and nobody is quite sure any more what breaks if a line moves. It is rarely the whole system: usually one module, one flow, one layer. The rest of the application works fine, and rewriting it whole would be a risk with no matching payoff.
Targeted refactoring works inside that exact boundary: we bound the area, write the safety net of tests that is currently missing, and change it one step at a time, each step small enough to reverse if something goes wrong. The system stays in production the whole way through: there is no cut-over day where the old version goes dark and the new one takes its place.
What targeted refactoring covers
The scope
We agree, before anything starts, which module or which flow the engagement covers and which stays out: that written boundary is what makes a fixed price and a fixed date possible in the first place.
Characterisation tests
Before touching a line we write the tests that pin down current behaviour, quirks and all: they exist to prove the refactor changed how the system works, not what it does.
Small, reversible steps
Each change is small enough to ship on its own and to roll back within minutes if something feels wrong, instead of one large, high-stakes rewrite landing all at once.
A record of the change
Whoever maintains that code after us finds a changelog entry for every step: what changed, why, and which characterisation test it had to keep passing.
How targeted refactoring works
Scope and starting point
We look at the flagged area together, agree what the engagement covers and what it doesn't, and measure the starting point: complexity, build times, whatever test coverage already exists.
Safety net
We write the missing safety net, calibrated to how the system actually behaves today rather than how it should behave in theory: it is what everything that follows leans on.
Refactoring in small steps
We change one thing at a time, each step shippable on its own, checking at every stage that the tests written earlier still pass.
Delivery and comparison
We hand over the code in production along with the measured before and after: how much complexity dropped, how build times moved.
What you get from targeted refactoring
- The changed code, in production, inside the scope agreed at the start
- The characterisation test suite, which did not exist before the engagement
- The measured before and after on complexity and build times
- A record of every step shipped, each one reversible on its own
- A short note on what changed and why, for whoever maintains it next
- An hour on a call to walk through the result and whatever comes after
When to refactor instead of rewriting, and when not to
- The system needs replacing outright, not repairing: that is a different conversation, starting from a different kind of engagement.
- Nobody can yet point to a clear boundary: buy the code audit first, that is what finds it.
- The code in question isn't actually slowing anyone down: if the real problem sits elsewhere, that budget is better spent there.
What targeted refactoring costs, and why
Unlike the two audits, which carry a closed range because we set the scope ourselves by looking at code that already exists, refactoring starts from €6,000 because you and we set the scope together before work begins: a small, isolated module lands near that floor; a layer that reaches across several services costs more; and we only know which once the boundary is agreed.
The figure follows the boundary, not the other way round: we agree what is inside the engagement and what is outside first, then price that exact scope, and from that point it is as fixed as an audit's. An unexplained 'from' would read like an evasion; here it simply means the final number depends on a decision made with you, not by us alone.
Targeted refactoring: frequently asked questions
- How much does a targeted refactor cost?
- From €6,000: the exact figure follows the scope agreed together before work starts, not a day-rate tariff. A small, self-contained module lands near that floor; an engagement reaching across several services costs more, because it means more characterisation tests to write and more steps to verify. Once the scope is set, the price doesn't move again.
- How long does a targeted refactor take?
- Between three and six weeks, depending on how wide the agreed scope is: an isolated module sits at the short end, a layer crossing several services at the long end. The duration is fixed alongside the price, before work begins, and covers both writing the characterisation tests and the change steps that follow.
- Will this break what already works?
- That risk is the whole reason the method exists. Before touching anything we write characterisation tests that pin down current behaviour, quirks included: if a later step breaks one, we know the same day, not at final delivery. Every change is also small and reversible for the same reason.
- Why write tests before touching the code?
- Because without a net proving what the system does today, a refactor is a gamble: it looks like an improvement right up until something stops working in production, too late to notice cleanly. Characterisation tests pin down real behaviour before we change it, so every later step checks itself against something concrete.
- How is the scope decided?
- We look together at where the code genuinely slows things down, not at what merely looks old: one module, one flow, one specific layer. That boundary gets written down before we quote a price, because it is what decides how many tests and how many steps the work needs. If the boundary isn't clear yet, the first move is an audit, not a refactor.