Six weeks is a constraint, not a boast
When we say a product ships in six weeks, the six weeks is doing the real work. An open-ended timeline invites open-ended scope; a fixed one forces the question every young product needs answered: what is the one loop users must be able to complete on day one?
That is why the timeline and the scope get agreed together, in writing, before the first line of code. The deadline is not a promise bolted onto a vague plan. It is the tool that makes the plan concrete.
Week zero: scope until it hurts
Before the build starts, we cut. Admin dashboards, settings screens, role systems, five sign-in providers: almost none of it belongs in a first release, and every piece of it competes with the one flow that actually proves the product.
The output of scoping is two lists: the core loop the MVP must nail, and a parking lot of everything we deliberately said no to, for now. Both lists go into the written proposal, so "is this in scope?" always has an answer on paper.
The stack that makes it possible
One senior engineer, one cross-platform codebase, and managed infrastructure. When we built ChildLink, our own co-parenting app, one Flutter codebase shipped to both app stores and Firebase replaced a backend that would otherwise have eaten weeks: Firestore kept both households in sync in real time with no server to write.
CI gets wired up in week one, before the app is feature-complete. Every build that later reached a store went through the same pipeline, so launch week was a routine, not a scramble.
Weekly demos keep everyone honest
Every week ends with a live demo and a short written update, and the staging build is in your hands from week one. Progress is something you click, not a status report. When something is off, it gets caught in week two, not in week six.
What six weeks is not for
Not everything fits. Connected hardware, heavy integrations, and products with certification requirements need their own timeline, which is why those builds start with a one-week scoping sprint instead of a promise.
But if your product is an app or a web product with one core loop worth proving, six weeks is usually enough to put it in front of real users. That is the point of an MVP: to start learning, six weeks from now instead of a year from now.