If you've spent any time around startup Twitter in the last twelve months, you've seen the claim. Ship your MVP in two weeks. Three weeks. Four weeks if the scope is big. It comes from agencies, freelancers, AI-powered tooling companies, and a growing genre of productised consultancies that have figured out the timeline is the marketing.
I run one of those consultancies. So I want to be honest about something: most fast-MVP claims are not true. Or rather — they are true under conditions that no one tells you about, and false under the conditions you'll actually find yourself in.
This post is about the difference between the two.
A note on the number. This piece used to say three weeks, because that was the shorter end of what I was quoting. I now quote four, everywhere, and I've rewritten this accordingly. Nothing about the method changed; the honest number did. Some builds still land sooner — a consumer AI build last spring had a working MVP in the founder's hands at the end of week one — but a promise you sometimes beat is worth more than an average you sometimes miss, and I'd rather publish the number I'm prepared to be held to.
What a four-week MVP actually requires
A four-week build is possible. I do them. The conditions under which it works are narrow, specific, and almost never the conditions a founder shows up with.
The first condition is scope discipline. Not as a value, as a practice. The product you can ship in four weeks is not the product you would design over six months — it is a different, smaller, sharper product that answers a specific question. The hardest part of the scoping call isn't deciding what to build. It's deciding what to leave out. The temptation, on every Sprint, is to ship one more thing. The discipline is saying no, repeatedly, to features that would be correct in a longer build and are wrong in this one.
The second condition is tooling. The work that used to take sixty working days now takes twenty because the tooling changed. Claude Code, modern AI pair-programming, and the AI-augmented IDEs do the heavy lifting on boilerplate, scaffolding, and the kinds of changes that used to eat a week. This isn't a vague claim about productivity gains — it's a specific shift in what a senior engineer's hands are doing all day. The ratio of deciding to typing has tilted hard toward deciding. A decade ago I would have spent week one on plumbing. Now I spend week one on the parts of the build that need a brain.
The third condition is reusable scaffolding. Not templates — templates lock you into someone else's choices. Scaffolding is the set of patterns, conventions, and pre-decided defaults that compound across projects. The auth flow I built once, I don't build again. The deploy pipeline I tuned once, I don't tune again. The first project takes a week longer than it should because the scaffolding doesn't exist yet. The tenth project takes a week less, because every decision that doesn't need to be made fresh is one more day for the parts that do.
The fourth condition is judgement. Ten years of engineering judgement, applied to the question "what does this build actually need?" If you don't have that judgement, you fall into one of two failure modes: you ship something that's missing a critical piece (the build is fast and useless), or you ship something with too much built in (the build is correct and late). Judgement is what closes the gap between fast and right.
Why the claim usually fails
When I see a fast-MVP claim that doesn't hold up, it's almost always because one of those four conditions is missing.
Scope discipline is the most common failure. The agency takes the founder's full feature list and tries to build all of it inside the window. By week two they're behind. By week four they're shipping half a product that doesn't work. The honest version of that engagement would have been a four-feature MVP shipped on time. The version that gets sold is a twelve-feature MVP shipped four weeks late.
Tooling is the second most common. A team that's been doing things the same way for five years can't suddenly cut their delivery time by two-thirds because they bought a Cursor licence. The tooling shift is real, but it doesn't apply itself — you have to have rebuilt the way you work around it. Most teams haven't.
Scaffolding is the third. The first build a productised consultancy ships is almost always over time, because the scaffolding doesn't exist yet. The honest founders work this out, charge appropriately for the first few engagements, and let the system mature. The dishonest ones promise a fortnight on day one and miss by three times that.
Judgement is the fourth and the hardest to fake. You can buy tooling. You can build scaffolding. You can teach scope discipline. You can't teach ten years of engineering decisions in less time than it took to live through them. Most fast-delivery claims are made by people who have the first three and not the fourth. The build ships on time and then dies in production six weeks later, because the parts that needed judgement got the version of the answer that fits in a sprint plan.
What the four weeks is actually for
The version of the Sprint I sell is not four weeks of building. It is four weeks of proving.
The MVP at the end of four weeks is not the product. It is the proof that the product is worth building. It answers a specific question the founder needed answered before they could justify the next six months of work — usually a question about whether the core thesis is true, whether the technology can deliver what they think it can, whether there's any signal at all.
The founder who runs a Sprint and gets a yes goes on to build the full product. Sometimes with me, sometimes not. The founder who runs a Sprint and gets a no — and there are no's — has just saved themselves six months. That outcome is rarer than the yes, but I count it as a win every time, because the alternative was that they would have spent the six months and got the no anyway.
The four weeks is for the proof. The proof is what gets a founder to the next conversation — the raise, the board meeting, the partner who needed to see it before signing. The proof is the deliverable. The product is the proof's vehicle. Most people sell it the other way round, and that's why most fast-delivery claims don't work.
Why I'm writing this
I'm writing it because I think the productised-consultancy category is going to get a lot bigger in the next two years, and most of what gets sold under that banner is going to be variations on the same set of broken promises.
If you're a founder shopping for someone to ship your MVP — at this price point, at this timeline — the question to ask is not can you ship in four weeks? Everyone says yes. The question is what are you going to cut? The honest answer to that question is the only thing that distinguishes a real Sprint from a marketing claim. If the person across the table doesn't have a strong opinion about what to leave out, the Sprint is going to slip. If they do, you're probably talking to someone who has done this before.
And if you've read this far and you have a build that looks like a Sprint, the link is at the top of the page. We'll spend thirty minutes on the call working out whether it actually is.