# Cheap code is the most expensive code The cost of changing software isn't constant — it follows a curve, and the shape of that curve is set by your architecture. Skipping SOLID, DRY, KISS, and DI doesn't save money; it moves the bill to later, with interest. Here's the economics, with the numbers. - **Author:** Fedor Chishchin - **Published:** 2026-06-02 - **Tags:** architecture, methodology, business - **Source:** https://fedorthinks.com/blog/cheap-code-is-expensive --- I've watched this movie more than once. A team decides to ship fast and skip the architecture — "let's just hack it for now, it's cheaper, we'll clean it up later." Month one, they're flying. Features land daily. Everyone congratulates everyone. Month nine, the same team needs three weeks to change a button, every estimate is wrong by a factor of three, and nobody touches the payment code because last time it took down checkout. The "cheap" version turned out to be the expensive one. This isn't a morality tale about doing things properly. It's economics. And the economics are more brutal than most people building software realize. ## The cost of change is a curve, not a number Here's the thing almost nobody prices in: **the cost of making a change to software is not constant.** Adding the same feature is cheap in one codebase and ruinously expensive in another. The difference is architecture. This isn't an opinion — it's an observed law. In the 1970s Meir Lehman studied how large systems evolve over decades, and one of his [laws of software evolution](https://en.wikipedia.org/wiki/Lehman's_laws_of_software_evolution) is _Increasing Complexity_: as a system evolves, its complexity rises **unless explicit work is done to reduce it.** Every change you make adds a little disorder. The next change has to navigate that disorder, so it costs a little more. Then it adds its own. The cost per change climbs. That's the curve. Effort-per-feature, plotted against time. Good architecture doesn't make change free — it keeps the curve flat. Bad architecture lets it go exponential. ## Two teams, same product Martin Fowler drew this years ago as the [Design Stamina Hypothesis](https://martinfowler.com/bliki/DesignStaminaHypothesis.html). Picture two teams building the same product. Plot cumulative features shipped against time. The team that skips design is **ahead at first** — they're not "wasting" time on architecture. But the lines cross. Fowler calls it the _design payoff line_. After it, the team that invested in design pulls away and never gives the lead back. The trap is that the early lead is real and visible — you can demo it. The crossover is invisible until you're well past it. By the time you feel the curve bending, you've already shipped your "MVP" on a foundation that can't take a second floor. You didn't save time. You borrowed it. ## Time is the currency, and the bill is enormous Every hour a developer spends fighting the codebase instead of building in it is money. And it is a _lot_ of hours. - Stripe's [Developer Coefficient](https://stripe.com/files/reports/the-developer-coefficient.pdf) survey found developers spend around **42% of their week** dealing with technical debt and bad code — roughly 13.5 hours on maintenance plus ~4 more wrestling bad code specifically. Bad code alone, they estimated at **$85 billion a year** in lost productivity. - McKinsey's research on [tech debt](https://www.mckinsey.com/capabilities/mckinsey-digital/our-insights/tech-debt-reclaiming-tech-equity) put it on the balance sheet: CIOs reported that **10–20% of the budget meant for new products** gets quietly diverted to servicing tech debt (a third of them said it's over 20%), and that tech debt is worth **20–40% of the entire value of their technology estate.** The companies carrying the _least_ debt grew revenue about **20% faster** than the ones carrying the most. Read those numbers as one sentence: **building cheap doesn't remove a cost, it relocates one.** You move it off the build budget — visible, one-time, the thing you were trying to shrink — and onto the maintenance budget, which is invisible, permanent, and compounding. You swapped a purchase for a subscription, and you didn't read the renewal terms. ## The wall The curve doesn't just get steep. Eventually it goes vertical. There's a point where adding a feature takes so long, or breaks so much, that you effectively _can't_ — the product stops being able to evolve. Meanwhile the competitor who kept their curve flat strolls past you adding the things your customers are asking you for. The dramatic version of this is [Knight Capital](https://www.henricodolfing.ch/en/case-study-4-the-440-million-software-error-at-knight-capital/): years of dead code left lingering in production, no real deployment discipline, and on one morning in 2012 a botched release reactivated code that should have been deleted. In **45 minutes** the firm fired off millions of unintended orders and lost **$440 million** — and ceased to exist as an independent company. Most teams never blow up that spectacularly. They do something quieter and, in total, more expensive: they grind to a halt. And then comes the most expensive project a company can attempt — the Big Rewrite. Nobody rewrites because the old code is ugly. They rewrite because the curve went vertical and there is no other move left. The rewrite is not the disease; it's the bill for the architecture you didn't buy, arriving all at once, at the worst possible time. ## "But moving fast means cutting quality" — no The objection I hear most is that architecture is the tax you pay to be slow and safe, and startups can't afford it. The data says the exact opposite. A decade of [DORA research](https://www.multitudes.com/blog/dora-metrics) (the _Accelerate_ program) keeps finding the same thing: the teams that deploy **fastest** also have the **lowest** failure rates. Speed and stability aren't a trade-off you balance — they're two outputs of the same cause: a codebase you can change with confidence. Good architecture is what buys the confidence. The "fast vs. good" choice is a false one; cheap teams just get neither, slowly. ## Where the rules actually pull the lever This is the part that matters in practice. SOLID, DRY, KISS, DI aren't academic taste. Each one is a lever on the shape of that curve: - **Single responsibility** (the S in SOLID): a change touches one place, not nine. The blast radius of every edit stays small — the difference between "two hours" and "two weeks plus a regression in checkout." - **DRY — one source of truth per fact:** when a rule lives in exactly one place, you change it once. When it's copy-pasted in eight, you change it eight times and miss the ninth — and the ninth is the bug that ships. - **KISS:** the simplest thing that works is the cheapest thing to understand, and most of the cost of software isn't writing it, it's _reading_ it. Every bit of cleverness you add today is a tax every future reader pays — including you, in six months, with no memory of why. - **DI — dependency injection:** when parts depend on contracts instead of concretes, you can swap, test, and change them in isolation. (I swapped the AI provider behind this very site by changing one config value, not rewriting the feature. That's DI buying a flat curve.) None of these are about elegance. Every one of them is about keeping effort-per-change from climbing. ## Why it's so hard to sell The reason "let's just hack it" keeps winning the argument is an accounting trick: **the saving is immediate and visible; the cost is deferred and invisible — and it lands on a different person.** The founder who said "cheap for now" books the win this quarter. The team that inherits the codebase pays the interest for years. That asymmetry is why the cheap option wins the meeting, right up until it loses the company. Which is also why almost nobody believes this from an essay. They believe it after they've lived it once — after the rewrite, after the quarter where the roadmap didn't move, after the senior engineer quit because every change had become a fight. Good architecture is the lesson you learn the expensive way and then never unlearn. The value of it arrives with the scar tissue. You can pay for architecture up front, in a currency you control: a little more design time, a little more discipline, a few principles held consistently. Or you can pay for the absence of it later, in a currency you don't: lost velocity, blown estimates, a product that can no longer move, and eventually a rewrite that may not finish in time. The bill comes either way. The only thing you're choosing is the interest rate. "Cheap" was never the cheap option.