The MVP is dead, long live the MVP!

For three decades, startup folklore has repeated the same advice: build the MVP in a way that can grow into the real product. That was sensible when software was expensive to produce, expensive to change, and expensive to rewrite. But AI coding has changed the economics. When even Y Combinator says a quarter of its Winter 2025 startups had codebases that were 95% AI-generated, we are not looking at a minor tooling improvement. We are looking at a shift in how cheap first-pass software has become.

That does not mean architecture is dead. It means the old definition of MVP is dying. The MVP used to be a tiny version of the final machine. Now it is increasingly a fast instrument for finding the right workflow, the right UX, and the right customer pain. In other words, the value is moving from code reuse to learning reuse. Thoughtworks has already published one of the clearest signals of this change under a title many engineers would once have dismissed as heresy: “Partner with the AI, throw away the code.”

That is why I think the middle row in the classic MVP diagram deserves a comeback.

Pre-AI, shipping a skateboard when your end goal was a car was often bad advice because you were creating a dead-end product. You still had to rebuild everything later, and rebuilds were painful. In the AI-agentic era, that dead end is far less dangerous. If you can get a working product in front of users today instead of spending the next month trying to make it “scalability-shaped,” the smarter move is often to launch the ugly thing, learn fast, and replace it once the market proves you deserve a second version.

So the right way is not “scale from day one.” The right way is build for replacement. That means you can be relaxed about future scale and still be serious about today’s feedback loop. You do not need bank-grade compliance to test with a small business. You do not need perfect multi-tenant elegance to validate a painful workflow for few early adopters. You need something users can touch, judge, complain about, and maybe pay for (I wish, haha). In the AI era, UX clarity and time-to-learning beat technical dignity far more often than most architects want to admit.

Of course, there is a catch. Cheap code also makes cheap mess. GitClear’s 2025 research, based on 211 million changed lines of code from 2020 to 2024, found growing signs of eroding code quality, including a sharp rise in copy-pasted and duplicated code. But... AI is evolving fast!

That is the distinction too many articles miss. The prototype can be disposable. The thinking cannot. The first version should be built quickly, but with enough discipline that you know what was validated, what users loved, what they ignored, and what must survive the rewrite. So yes: “Build the MVP so you won’t need to rewrite it” is becoming bad advice. Build it so you can test the market immediately. Build it so you can throw it away without mourning. And if the market says yes, do not scale the prototype. Rewrite the winner.

If this resonates with you, ask me how to implement it in your organisation. Happy to help!