Why your MVP got harder to change in week four
Three weeks of astonishing progress, then everything takes a day. The cause is almost always the same, it is visible from the outside, and it is fixable before it compounds.
· 6 min read
There is a shape to AI-assisted projects that we now see often enough to predict. Weeks one to three are genuinely remarkable — features land in hours, the demo gets better every day, and everyone involved starts revising their estimate of how fast software can be built. Then somewhere around week four it stops. Not dramatically. Things just start taking a day that used to take an hour.
People usually blame the tool, or assume they have hit the hard part of the product. It is almost never either.
The cause: the same problem solved five times
Each prompt gets answered on its own terms. Ask for a screen that lists orders and you get code that fetches orders, formats dates and handles the empty state. Ask for a screen listing invoices and you get all of that again — written slightly differently, in a different file, with a different name for the same idea.
Nothing about that is wrong. Every piece works. But you now own five ways of formatting a date and four ways of fetching a list, and no one wrote down which is which. Changing how dates look is five edits and four chances to miss one.
Nothing is broken. Everything is just slightly more expensive than it should be, forever.
This compounds quietly. Duplication has no symptoms in week one, because there is only one copy. It has mild symptoms in week three. By week six the cost of every change is multiplied by however many copies exist, and the number of copies has been growing the whole time.
How to tell from the outside
You do not need to read the code. These three signs are enough, and you will recognise them:
- A change you thought was cosmetic keeps missing a place. The date format changed in three screens and not the fourth, and nobody predicted the fourth.
- Fixing one thing breaks another that seemed unrelated. That is two copies of a rule that used to agree.
- Estimates have quietly stopped being useful. The same person who was accurate in week two is now wrong by a factor of three, because the cost of a change no longer depends on the change.
What to do once you have it
Do not rewrite. It is the instinct and it is wrong — a rewrite throws away working, tested behaviour to solve a problem that is about organisation, not correctness.
Consolidate the duplicates that are actually costing you, in order. Find the thing you have changed most often — usually data fetching, dates, money, or permissions checks — and make it exist once. Then the next one. Two or three of those recover most of the lost speed, because duplication is never evenly distributed; a small number of ideas account for most of the pain.
Add a test as you consolidate each one. Not for coverage — so that the next time something reaches into that logic, you find out immediately rather than in a support message.
Avoiding it next time
The cheap prevention is a recurring question rather than a process: every few days, ask what has been written twice. AI tools will happily answer it about their own output if you point them at the code and ask. What they will not do is ask it unprompted, because each prompt is a fresh conversation with no memory of the shape of what already exists.
That is the whole gap, really. The tools are excellent at producing a correct answer to the question in front of them. Keeping a codebase coherent is a different job — it is about the questions nobody asked — and for now it is still ours.