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 three-week 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.
What a three-week MVP actually requires
A three-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 three 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 days now takes fifteen 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 three-week 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 in three weeks. By week two they're behind. By week three 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 75% 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 three weeks on day one and miss by twice 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 three-week 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 three weeks is actually for
The version of the Sprint I sell is not three weeks of building. It is three weeks of proving.
The MVP at the end of three 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 three 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 three-week 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 three 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.