Ask a founder why their MVP took eight months and the answer is usually about engineering. It almost never is. The build ran long because nobody had the authority, or the incentive, to say no to a feature. The proposal grew, the invoice grew with it, and by the time anything shipped the assumptions underneath it had quietly expired.
The four-week MVP is not a promise about developer velocity. It is a claim about scope discipline. If the scope is genuinely cut to the bone, four weeks is unremarkable. If it is not, four months will not save you either. The deadline is a symptom of the decision, not the decision itself.
The proposal is the problem
Agencies are usually paid to build, so a longer feature list is a bigger contract. That is not malice; it is the shape of the commercial arrangement. Nobody in the room is rewarded for removing things, so nothing gets removed. The MVP arrives as a Frankenstein of reasonable requests, each defensible on its own, none of them collectively proving anything. A product that does everything a little is a product that tells you nothing clearly.
The harder question is not what to build but what you are willing to launch without. That is a founder decision, not an agency one, and it is the decision most projects avoid until the budget has already gone.
Live beats complete, and it is not close
An MVP's job is to replace a guess with evidence. Every week it sits in Figma, it produces no evidence at all. Founders often treat launching as the reward for finishing, when in fact launching is the beginning of the only research that counts.
This is where the demo trap bites. A build tuned for a meeting room works beautifully in a meeting room: the happy path is polished, the edge cases are absent, and the first real user finds the crack within a day. That is not a launch, it is a rehearsal. A good result looks different in a specific way: a live URL that strangers can use, error states that were considered rather than discovered, and an architecture that will not need to be thrown away the moment traction arrives.
What a good four weeks produces
The output that matters is not just the app. It is the things that let the product keep moving after the agency leaves: source code and history the next developer can actually follow, analytics that show what users did rather than what they said, and written reasoning behind the technical choices so the next hire inherits clarity instead of archaeology.
A founder should also expect pushback. A team that never questions the scope is a team padding an invoice. The right partner tells you early what they cannot do well rather than discovering it in week three. Speed, in the end, is a byproduct of honesty about what is being left out.
The full breakdown of how that scoping and build actually runs week by week, including the delivery package and the architecture decisions behind it, is set out in Foundry 5's guide to MVP development in London.
Top comments (0)