A founder we worked with had a choice between a $15,000 build and a $65,000 one. He took the $15,000 build, and by any reasonable measure he was right: he got a working product, real users and a seed round out of it. Eighteen months later he spent $210,000 replacing it.

That is not a story about a bad vendor. The product did what it was paid to do. The mistake was treating the invoice as the cost, when the invoice is only the deposit.

Technical debt charges five taxes

Debt is not the code being ugly. It is every future decision costing more than it should. It shows up in five places, and all five are measurable.

• The velocity tax. Features that should take three days take nine, because nothing is tested and every change breaks something unrelated. On a team of four, a 2x slowdown costs roughly $30,000 a month in salary buying half the output.
• The incident tax. Outages, data corrections, angry support threads. Not just engineering hours — churned customers who never explain why they left.
• The hiring tax. Strong engineers interview your codebase as much as you interview them. A repository with no tests and no documentation costs you the candidates you most wanted, or costs you 15–20% more to convince them.
• The deal tax. Enterprise buyers send security questionnaires. Investors send technical reviewers. Every unanswerable question is a discount you did not plan to give.
• The rewrite tax. Eventually the only way forward is backwards. A rewrite always costs more than the original build, because now you must also replicate behaviour nobody documented while keeping the old system alive.

The year-two arithmetic

Take the $15,000 build. Year two looks like this: two engineers at reduced output for eight months, one enterprise deal lost on a security review, three months of dual-running during the replacement, and the $210,000 rebuild. Even discounting the lost deal, the real cost of that decision was north of $300,000. The $65,000 option would have been the cheap one.

This is not an argument for spending more. It is an argument for knowing which line you are on.

What actually separates the two

The difference between the builds was never the number of features. It was these:

• Automated tests around the parts of the system that hold money or personal data.
• A deployment pipeline any engineer can run, rather than one person who knows the ritual.
• Access control designed once, at the data layer, instead of checked ad hoc on each screen.
• Written decisions — why this database, why this queue, why this trade-off — so the next team does not have to guess.
• Dependencies chosen for maintenance, not for novelty.

None of it is glamorous, and none of it is visible in a demo. That is precisely why it gets cut from proposals competing on price.

How to spot the cheap build before you sign

1. Ask what percentage of the estimate is testing. If the answer is zero or "we test manually", you are buying the cheap build.
2. Ask to see a repository they handed over eighteen months ago. Not a demo — a repository.
3. Ask who is on call after launch and what happens at 2am. Silence here is expensive later.
4. Ask how a new engineer would get the project running locally, and how long it takes. Anything over an hour signals what maintenance will feel like.
5. Ask what they would refuse to build for that budget. A partner who will not say no to anything has already decided to leave the hard parts to you.

You do not get to choose whether you pay for quality. You only choose whether you pay for it now, at cost, or later, at a premium, under deadline.

Every system we build is audit-ready by default — tested, documented, and handed over with full IP on day one. If you have inherited something that is not, a short technical audit will tell you which of the five taxes you are already paying.