The most common way to kill a startup is to spend eight months building something nobody asked for. When CB Insights analysed hundreds of startup post-mortems, "no market need" sat near the top of the failure list, alongside running out of cash. The binding constraint on shipping quickly is scope rather than effort, and this startup MVP guide lays out a six-week path from idea to a working product in front of real users.
An MVP is a learning instrument, not a small product
A minimum viable product is the smallest version of a product that tests your riskiest assumption against real user behaviour. Eric Ries defines it as the fastest route through the build-measure-learn loop with the least effort, which means its output is validated learning rather than revenue or polish. If version one cannot tell you whether the core idea works, it is not an MVP, only an unfinished product.
The classic examples are strikingly small. Dropbox tested demand with a three-minute demo video that grew the waitlist from 5,000 to 75,000 people overnight, and Buffer went from idea to paying customers in seven weeks starting with only a landing page and a pricing page. Judge your MVP by the same standard: how quickly it produces evidence.
Six weeks is a scoping decision, not a speed record
You do not hit a six-week deadline by typing faster. You hit it by choosing one core workflow and declining to build anything else. Pendo's analysis of feature usage found that 80% of features are rarely or never used, which the report priced at roughly $29.5 billion in wasted R&D, and a pre-launch team guessing at requirements will do worse. So before week one, write the scope as a single sentence: a specific user can do the one thing and gets the one outcome. Everything else is cut, deferred, or faked.
Faking is legitimate. Admin dashboards become SQL queries run by hand, billing becomes Stripe Payment Links or a manual invoice, and the second user persona simply does not exist yet. This concierge pattern keeps the engineering surface small enough for the timeline to hold.
Weeks 1 to 4: discovery, a prototype strangers can click, then one workflow
Week one contains no production code, deliberately, because rushed scoping is the most expensive mistake in the whole process. A short, structured technical discovery phase compresses that risk into days and ends with four written artefacts: a one-page problem statement, the one-sentence workflow plus the five to eight screens it implies, a "not now" list recording every deferred feature, and a boring stack decision built on one language your team knows, one managed database, and one deployment target. Talk to five real potential users this week, in conversations rather than surveys.
By mid-week two you want a clickable Figma prototype covering the core workflow end to end, tested on five strangers before you write significant code. This costs two days and routinely deletes entire screens, and every screen deleted here is roughly a week of building you never pay for.
The build stretch rewards sequencing over hours. Set up continuous deployment before the first feature and push a walking skeleton to production on day one. DORA's 2024 State of DevOps research found elite performers deploy on demand with lead times under a day, and shipping daily is a far easier habit to adopt now than to retrofit. Buy the undifferentiated parts such as auth, payments, email and hosting, keep exactly one environment besides production, write tests only for the money path, and timebox every rabbit hole to half a day. The same discipline applies to a SaaS product build; the stack changes shape but the scope rules do not.
The split flexes with complexity. Industry surveys place simple MVPs at 4 to 8 weeks and $15,000 to $50,000 or more, so six weeks assumes you held the line on a single workflow.
Weeks 5 to 6: instrument, beta test, launch, review
An MVP without measurement is a demo. Before beta users arrive, wire up the few numbers that answer your original hypothesis: activation, meaning the user completed the core workflow once, retention, meaning they returned, and one domain-specific success event. A basic PostHog setup takes an afternoon.
Then run a private beta with 10 to 30 people who genuinely have the problem, which excludes your friends and your investors. Watch three of them use the product live on a screen share, fix the top three issues only, and send the rest to the "not now" list. Launch week is smaller than founders imagine: open access, announce in the channels where your users already gather, and end the week with a learning review rather than a party. BLS data shows about 20% of new businesses fail in year one and roughly half by year five, and survival often comes down to how early the bad news arrived.
The honest comparison with a six-month build is that the long build defers first real feedback until month five or six while carrying the unused-feature risk Pendo measured, and it earns its keep only after validation or in heavily regulated domains.
FAQ
How much does an MVP cost?
Agency and dedicated-team builds run roughly $15,000 to $150,000 depending on complexity, with single-workflow products at the low end. A landing-page or concierge test can validate demand for a few thousand dollars first.
Can I validate an idea without building anything?
Yes, and often you should. Dropbox used a demo video and Buffer used a pricing-page test before writing product code, so if a smoke test can answer your riskiest question, run it before committing to the build.
Your six-week launch checklist
Write the one-sentence scope: specific user, one action, one outcome.
Run technical discovery in week one and start the "not now" list.
Test a clickable prototype on five strangers by week two.
Deploy a walking skeleton on day one, and buy auth, payments, email and hosting.
Instrument activation and retention, run a 10 to 30 person beta, then launch and hold a learning review.
Six-week ships come from making the scope argument once, in week one, and never reopening it. BeyondPixl Studio runs this exact playbook with founders, from discovery through launch, and the hard part is never the code; it is the cutting. Talk to our engineering team about scoping your MVP build.