Beware of anyone selling an MVP in six weeks
It is one of the most repeated promises in the industry: "your MVP in six weeks". It sounds concrete, it sounds bold, and it gives anyone starting out exactly what they want to hear: a date. The problem is not that it is a lie. It is that it was made before anyone could know whether it was true.
"MVP" is not a unit of measurement
An MVP can be a tool that replaces a freelancer's spreadsheet. And Google was an MVP: a search engine with a new algorithm and a monetization system underneath. Both go by the same name and have nothing in common. "MVP" describes an intention (the smallest version that lets you validate the product), not a size. And something with no size cannot come with a standard deadline.
What sets the size is a question that whoever promises deadlines never gets around to asking: what does your MVP need to prove? For one founder, it is that someone will pay. For another, that a process done by hand today holds up once it is automated. For another, that their algorithm returns something useful. Each answer draws a different scope, and each scope, a different timeline.
That is why "six weeks", said before anyone has studied your product, is not information: it is marketing. The real timeline depends on the scope, and the scope depends on what the product is. Nobody can know that before getting to know it.
The three ways out for whoever makes the promise
The promise is easy to make, but the day comes to keep it. Whoever made it has three ways out, and they are worth a close look, because none of them is good for you.
Cut the scope until there is no product left. Six weeks are enough for something; the question is whether that something validates your idea or just looks like it. The word "minimum" is elastic, and in the wrong hands it absorbs any cut: you get "an MVP" you cannot show to a customer and that does not answer the hypothesis you wanted to test. The date was met; the product was not.
Pad the price. If the deadline is fixed and the scope uncertain, the risk has to be paid for, and it goes into the price as a cushion. It is the same mechanism that makes us distrust fixed project prices: you overpay to fund someone else's promise.
Renegotiate when something unplanned shows up. And it will, because the promise was made without looking. Week six arrives, the product is not there, and the conversation stops being about your product and turns to change orders and blame. How that road usually ends, we covered in cheap development, expensive maintenance.
And the three are not mutually exclusive. What you usually see is all of them in a row: first the scope gets cut, then the deal gets renegotiated, and the cushion was charged from the start.
The risk nobody mentions
The important nuance: sometimes six weeks really is possible. Some products fit in that time. But you find that out after studying the case, never before. The honest approach is exactly that: study your product and give you a tailored option, with its scope, its order and the reasoning behind it.
Whoever gives you a date without studying anything is taking a risk: that they guessed right by chance. And whoever takes a risk without telling you is, quite literally, a risk to you. Not because they are bad people, but because when that risk materializes, the problem will be yours: your product late, your budget renegotiated or your "minimum" unrecognizable.
The signal is easy to read, too: count how many questions they asked you before giving you the date. A proposal that arrives with a date and no questions is a template, and your product has not made it into it yet.
We do not give a total deadline either
The honest contrast is not "we really can do it in six weeks". It is that we do not tell you how long your whole product will take before we know it either, because we do not know. After studying it, we do: we walk you through it item by item, with the reasoning for each one next to it.
What we do give is a date that does not depend on the size of your product: the first delivery, two weeks after starting. The architecture decided and documented, the environments deployed and a first screen working. From there, you set the pace month by month, according to your budget: more dedication when the project needs a push, less when it makes sense. The deadline stops being someone else's promise and becomes your decision, with working software on the table every two weeks to check it against.
That first delivery has another purpose, too: it is the cheapest way to test whether your vendor delivers what they promise. Two weeks of investment instead of six weeks of faith.
If you are comparing proposals and one arrives with the date already filled in, ask two questions: what gets cut if the date is not met, and who pays for the cushion if it turns out not to be needed? Whoever has thought about your product has answers; whoever sold you the date does not. And if you want the version studied for your case, with scope, order and a first delivery with a real date, tell us what you want to build.