Type at least 3 letters to search

·10 min read

Technical Debt After an Audit: What We Fix First and What It Costs

A stone building with scaffolding on one floor while the other floors stay lit and working, and a notebook with a ranked repair list: security and access underlined in red, then what blocks revenue, what blocks change and style

Most companies already know they carry technical debt. The hard part comes after the audit: what to fix first, what to leave, and how to pay it down without stopping the business. Here is how we do it, on our own cases, and what it costs.

Why now

The bill comes later

Technical debt is the price of every shortcut a product took to ship: an old framework nobody upgraded, a module copied instead of reused, a setting only one person understands. It does not show on a balance sheet. It shows as features that take three weeks instead of one, pages that slow down under load and an upgrade that keeps moving to next quarter.

The problem is not new, but it is growing. In the 2024 Stack Overflow survey technical debt was the top frustration of developers, named by 62% of them. In Sonar's survey of January 2026, AI accounted for 42% of committed code, and only 48% of developers said they always check it. AI lets a team build in a year what used to take three, and it can pile up three years of debt just as fast.

Buyers have noticed. In KPMG's technology M&A survey, 66% of dealmakers discuss technical debt when they plan a deal and only 33% actually investigate it. The gap gets paid after closing. Our partner brand The Structure collected the market numbers, review prices and repair prices in Technical debt in 2026: demand, review prices and repair costs.

The map

An audit that leads to a plan

An audit is worth what you can do with it. A list of two hundred warnings from a code scanner is not a plan, and neither is "the code has tech debt". What we need from an audit, ours or anyone else's, is each finding tied to its business effect: what it slows, what it risks, what it blocks, and a rough cost to fix.

We work from three kinds of starting points:

  • Our own review before we take a project over, when code comes from another contractor. The takeover audit starts from $3,000 and is described in Taking Over a Website or App From Another Developer.
  • An audit of what the company actually owns: domains, accounts, licences, access and code, which often turns up debt nobody counted. It starts from $2,000.
  • A report from an outside reviewer, including a technical due diligence before a sale. We take its findings as they are and turn them into an order of work.

An audit is worth what you can do with it.

Order

What we fix first

We sort findings by what they cost the business, not by how ugly the code looks. The order is almost always the same:

  • Security and access first. Unsupported versions with known holes, shared passwords, former contractors who still have keys, backups nobody has restored.
  • Then what blocks money. Forms that lose leads, checkout steps that break, pages that load too slowly for search or for people on phones.
  • Then what blocks change. The old framework version every other upgrade depends on, the module only one person can touch, the missing tests around the parts that change most.
  • Taste last. Naming, structure and style matter, but they rarely justify a budget on their own. They get fixed along the way, in the files we already open.

A finding that changes neither risk nor revenue nor speed waits. It goes into the register with a note, so nobody rediscovers it as a surprise.

Our cases

Three debts paid down, one next in line

Our own site, Laravel 7 to 13. peretz.agency ran reliably on Laravel 7 and PHP 7, both long out of support. Laravel cannot skip major versions, so the move meant six separate migrations, one version at a time, on a closed staging copy with a written way back. It took about three days of development. The two traps that would have taken the whole site down were caught on staging, not in production. The full story is in Six Laravel Versions in Three Days.

The Structure, from a static generator to Laravel. A live site built by a Python script had to become a Laravel application without a visitor noticing. We set one rule: every page must render the same bytes as before, checked automatically for every address, with one command to go back. Rounding, JSON and escaping differences between the two languages surfaced in the check and were fixed before the switch. That case is in Moving The Structure to Laravel Without Changing a Single Byte.

A specialty clinic that wanted a new site. The owner told us that nothing worked and was ready to pay for a new website. We started with the debt instead: forms that were not connected, wrong phone masks, empty pages, an outdated price list, an old PHP and an old version of the shop platform. We updated PHP and the platform within its branch, kept the design and refreshed it. The first new pages brought three requests in five days. The case is in Website Design for Specialty Clinics.

MEDPRESSO, next in line. We built the MEDPRESSO project, and now we are preparing it for its next stage. Part of that preparation is a move to the current version of Laravel. The order is the same as on our own site: first a map of versions and dependencies, a closed copy and a written way back, then one version at a time, with nothing changing for the people who use it.

No rewrite

Why we rarely start over

A rewrite is the most tempting answer to debt and usually the most expensive one. It looks clean in a plan. In practice it stops new work for months, loses the small fixes that years of real use put into the old code, and arrives with debt of its own.

We rewrite a part only when it costs more to keep than to replace and when it can be replaced on its own, behind a clear boundary. Everything else is paid down in steps on the live system: one upgrade, one module, one set of tests at a time, each step with a way back. The business keeps running, and every week the system gets a little cheaper to change.

The business keeps running while the debt goes down.

Before a sale

When a buyer will check the work

Buyers take this part seriously: in the SRS Acquiom due diligence study, 51% of US investment bankers called technology diligence the most burdensome part of the review. When a company prepares for a sale, the order shifts toward what a buyer's reviewer will read: security and access, ownership of code and accounts, data handling and anything that only the founders can run. A fixed issue with evidence reads very differently in a data room from the same issue found by the buyer.

If the review is done by The Structure, the separation is strict. The Structure writes the findings and the plan, and the client may give the work to any team. When we do it, our work is checked by a separate team of senior engineers who took no part in it, against the same evidence as anyone else's, and the report states who made each fix. A buyer can always commission its own review of the parts we touched.

The team

European engineers, prices below the US

The repair is done by our engineers in Europe and Ukraine. They have worked, and still work, on large international projects, where an upgrade is planned like a release and a broken page is an incident, not an inconvenience. We bring the same standard to every codebase, whatever the size of the company: a plan before the first line, a closed copy, a way back and a check by someone who did not write the change.

European quality does not have to come at US prices. US agencies most often charge $100 to $149 an hour for whoever they put on a project. With us $100 an hour buys a senior engineer, and a middle engineer costs $55 to $75, which is often all a repair needs.

AI tools take a large share of the routine: they read a codebase quickly, draft the mechanical changes of an upgrade and write tests around old code. Our engineers check every such change, and the time saved goes to what a tool cannot do: deciding what is worth fixing, proposing improvements and new features, and leaving the client with a product that is better, not only tidier.

European quality does not have to come at US prices.

Prices

What paying down debt costs

The audit is the small part of the bill. Our current prices:

  • Takeover audit before we take on someone else's code: from $3,000.
  • Audit of digital ownership (domains, accounts, licences, access): from $2,000, larger businesses from $3,000.
  • Technical due diligence: a session for $1,500, a full review from $7,500.
  • The repair itself is priced from the audit as a fixed project or by the hour: about $100 an hour for a senior engineer, $55 to $75 where a middle engineer is enough.
  • After the repair, support from $1,000 a month keeps versions current, so the debt does not grow back. For a team that needs technical leadership without a full-time hire, a fractional CTO from $3,500 a month.

For comparison, published fixed-price rescue programmes for a production codebase are commonly $25,000 to $50,000 and go up to $100,000 for complex products. Our own Laravel 7 to 13 move took about three days of development because the order of work was settled before the first line changed.

FAQ

Questions about paying down technical debt

What should we fix first after a technical debt audit?

Security and access first: unsupported versions, shared passwords, old contractors with keys, untested backups. Then whatever blocks revenue, such as broken forms or slow pages, then what blocks future changes. Style and structure come last and are best fixed along the way.

Is it better to rewrite the system or fix it step by step?

Usually step by step. A full rewrite stops new work for months and brings its own debt. We replace a part only when it costs more to keep than to replace and can be cut out on its own; the rest is upgraded on the live system, one step at a time, with a way back.

How much does it cost to pay down technical debt?

Our audits start from $2,000 to $3,000 depending on the type, and technical due diligence from $1,500 for a session. The repair is priced from the audit, as a fixed project or at about $100 an hour for a senior engineer and $55 to $75 for a middle one. Support from $1,000 a month keeps the debt from returning. The work is done by engineers in Europe and Ukraine at rates well below those of US agencies.

Can you fix the findings of a due diligence report written by someone else?

Yes. We take the findings as written and turn them into an order of work. If the report comes from The Structure, our fixes are checked by a separate team of senior engineers who took no part in them, and the report states who made each fix.

Sources

Have an audit, or a feeling that every change takes too long? Let's turn it into an order of work.

Book a Strategic Session

Project Takeover