Your MVP Got Cheap. Year Two Got Expensive

Building the first version of your product got cheap. Keeping it did not. AI coding tools have compressed work that used to fill a twelve-week build into a few weeks, and every founder we talk to has noticed the quote go down. What almost nobody has priced is the other end of the product's life: the code that arrives that fast is measurably harder to change afterwards, and afterwards is where most of a software budget has always lived.

What actually got cheaper?

The greenfield part: the first build, on an empty repository, with no existing system to respect. That is the task these tools are best at, and the size of the advantage is now measured rather than guessed. Stanford research cited in DORA's ROI of AI-assisted Software Development report puts productivity gains at 35% to 40% on simple, greenfield tasks, and at roughly 10% on complex legacy code (InfoQ, May 11, 2026). Put those two numbers side by side and the shape of the problem appears. The discount applies to the month you are in. It shrinks by about three quarters the moment your product has a past.

Why does year two cost more than it used to?

Because what makes year two cheap is reuse, and reuse is exactly what AI-assisted codebases are losing. GitClear and GitKraken analysed 623 million real-world code changes from 2023 to 2026 and found block-level duplication up 81%, refactoring line moves down 70% against 2022 levels, long-term legacy maintenance down 74%, error-masking constructs up 47%, and function connectivity down 35% — from 343 method calls per thousand changed lines to 223 (LeadDev, July 7, 2026). Those are five views of one event. Code is being written fresh instead of being reused, so the same behaviour ends up implemented in five places. It works. It ships. Then you change your pricing, and five places have to agree.

What does that cost look like in money?

DORA's report puts a number on both sides. It models a first-year return of about $11.6 million against $8.4 million of investment for a 500-person engineering organisation — a 39% return with an eight-month payback — while the same calculator books a negative $344,000 for downtime as the change failure rate rises from 5% to 6% (InfoQ, May 11, 2026). Notice who that model describes: five hundred engineers, a review process, and enough slack to absorb one extra point of failure rate. You do not have that. On a product run by a founder and one contractor, a point of extra instability is not a line item on a spreadsheet. It is your week.

What should you do differently before you build?

None of this is an argument for building slower. It is an argument for spending part of the time AI handed back on the things it does not do for you: deciding what the product must not do, keeping exactly one implementation of anything that touches money or identity, and making sure a human can explain the system without opening the tool that wrote it. The list below is what we walk through before scoping a build, and it is short on purpose.

When is an AI-built first version the right call?

When the product is small, the risk of being wrong is high, and you intend to throw it away. A rough build that answers "will anyone pay for this" in three weeks is worth more than a maintainable build that answers the same question in three months — provided everyone agrees in advance that the answer is the deliverable and the code is not. The failure mode is not building fast. It is building fast, getting a yes, and then running a real business on the prototype for two years because it was already there. Anyone telling you that AI removed the maintenance question is selling you the first three weeks.