The Basetool 6-Week MVP Method
Our named methodology for shipping a production-ready MVP in six weeks. Fixed scope, fixed price, three phases. This is exactly how we work.
Contents
When founders ask how long it takes to build an MVP, the honest answer is: it depends on how much discipline everyone exercises. We have built the discipline into the structure itself.
The Basetool 6-Week MVP Method is our fixed methodology for shipping a production-ready MVP. It is not a range or an estimate. It is the container. If a feature does not fit in six weeks, it does not go into this engagement. That constraint is not a limitation; it is the product.
Our process on the homepage. Here is what it looks like in detail.
Phase 1: Discovery and Spec (Weeks 1-2)
The first two weeks are not about writing code. They are about eliminating ambiguity before a single line is written.
What happens:
- We run a structured kick-off call (usually two to three hours) to map the core user journey. One user type, one flow, one hypothesis we are testing.
- We produce a functional spec: written user stories, annotated wireframes for every screen, and a data model draft. Nothing is left to interpretation.
- We make all the decisions that cannot be changed cheaply mid-build: database structure, authentication approach, third-party integrations, hosting environment.
- We identify the scope boundary explicitly: meaning we write down what is NOT in this build, so there is no ambiguity later.
Who owns what:
- You (the founder) own the product decisions: what the core workflow is, who the user is, what success looks like.
- We own the technical decisions: stack, architecture, deployment approach.
- We jointly own the spec: every item is reviewed and signed off before Phase 2 begins.
What decisions happen here:
The most important decision in Phase 1 is the scope line. We draw it together, and once drawn, it holds. This is where over-scoped MVPs get fixed, not by negotiation, but by working through the spec and recognising which features are testing the hypothesis and which are decorating it.
Phase 2: Build (Weeks 3-5)
Three weeks of focused development. The spec is the source of truth. No new features enter the build during this phase.
What happens:
- Week 3: Core infrastructure. Authentication, database, API scaffold, deployment pipeline to a staging environment. By the end of Week 3, the staging URL is live and the skeleton of the product is navigable.
- Week 4: Core features. The primary user journey is implemented end-to-end. This is where the product starts to look like the thing it is supposed to be.
- Week 5: Secondary flows and polish. Error handling, edge cases, empty states, loading states, responsive layout. The product is made reliable enough to show to real users.
What you see:
We share the staging URL at the end of Week 3 and provide weekly async updates. You are not expected to review every commit, but you are expected to flag any spec misunderstandings before Week 5 closes. Week 5 is the last point at which a course correction can happen without affecting the launch date.
The discipline:
Phase 2 has one rule: the scope is frozen. If you identify a feature that should be included, we add it to a backlog for post-launch. We do not adjust the scope mid-build. This is not rigidity. It is what makes a six-week launch possible. Scope additions mid-build do not add time linearly; they add it exponentially, because they create integration work, re-testing, and cognitive overhead that compound.
Phase 3: QA, Polish, and Launch (Week 6)
The final week is structured around a single question: is this product ready to put in front of real users?
What happens:
- Cross-browser and cross-device testing. We verify the product on the environments your users will actually use.
- Edge-case review: what happens when a user does something unexpected? Empty database states, failed payments, broken email links: these all get exercised.
- Performance baseline: we verify the product loads quickly enough that it does not create friction on first use.
- Staging to production promotion: the environment is moved from staging to production, with the real domain, real credentials, and a pre-launch checklist completed.
- Handover documentation: we produce a short technical handover covering architecture decisions, how to deploy updates, and where the credentials live.
The launch:
We define "launch" as: real users can sign up, use the product, and encounter a working experience. Not perfection. Working. The distinction matters. A perfect product that ships in four months has cost you four months of learning. A working product that ships in six weeks is six weeks of real signal.
Why six weeks
Six weeks is not a round number we chose arbitrarily. It is the interval we have found keeps a team of two to three engineers in a focused sprint before the cognitive overhead of context-switching becomes a drag on quality.
It is also the interval that forces a scope conversation before the build. The six-week limit makes scope discipline unavoidable: if you want to launch in six weeks, you have to choose what to build. That choosing is itself valuable.
Beyond six weeks, scope tends to expand. Beyond ten weeks, the thing being built starts to look different from the thing that was designed at the start, because the world changes and the product changes with it. And then you are no longer testing a hypothesis, you are building a product you hope the market still wants.
What is NOT included
To be direct about the scope boundaries:
- Not included: native mobile apps. Web only, responsive.
- Not included: a public API or partner integrations. Post-launch.
- Not included: admin panels beyond basic operational tooling. You are your own admin.
- Not included: complex analytics dashboards. A standard analytics integration (e.g. Vercel Analytics, PostHog) is included; custom reporting is not.
- Not included: multi-language support. One locale.
- Not included: custom email template design. Functional transactional email is included; branded HTML email campaigns are not.
These are not afterthoughts. They are intentional. Everything on this list is something that can be built in the phase after you have validated that the core product works.
The fixed-price question
The Basetool 6-Week MVP Method operates on fixed scope and a fixed engagement structure. Predictable budget, no scope drift.
This requires that the scope is genuinely fixed. Variable scope with a fixed price is not a pricing model. It is a conflict waiting to happen. When we agree on the scope in Phase 1 and both parties sign off, the price is fixed because the work is fixed. If scope changes after Phase 1, we discuss the impact before proceeding.
Getting started
If you have an idea and want to understand whether it fits the six-week model, the MVP Estimator is the place to start. It walks through the scope decisions and surfaces the trade-offs before we have a conversation.
If you are already clear on what you want to build, reach out directly. The Discovery phase starts with a call, and the call is the beginning of the spec.
This methodology reflects how we work at Basetool Labs as of 2026. It evolves as we learn.