How we ship an MVP in six weeks

Six weeks isn’t a magic number. It’s short enough that you can’t hide from your own decisions, and long enough to put something real in front of a real person. Almost every founder we meet arrives with the same problem — a roadmap with forty items on it and no clear sense of which one matters. A deadline this tight drags that question into week one, where it belongs.

We’ve run this loop enough times that it’s less a process and more a set of habits. Here’s how a six-week build actually goes, and the rules that keep it honest when the temptation to add “just one more thing” shows up — and it always shows up.

Week one is for cutting, not coding

We spend the first few days arguing about what to leave out. Not the database schema or the framework — the feature list. Most ideas are three products wearing a trench coat, and trying to build all three at once is how you end up with none of them finished. So we keep asking one question until it hurts: what is the single thing this product has to do for someone to find it useful? Everything that isn’t in direct service of that answer goes on a “later” list, no matter how good it is.

If the scoped-down version doesn’t make you a little nervous about how small it is, you haven’t cut enough.

That nervous feeling is the signal you’re looking for. A launch you’re slightly embarrassed by is one you can actually ship, learn from, and improve. A launch that has everything is one that never arrives — it just keeps getting one sprint further away.

By the end of week one we want a feature list you could write on the back of a napkin, a clickable sketch of the core flow, and agreement on the one metric that tells us it’s working. That’s it. No tickets for features we’re not building yet.

Build in thin vertical slices

Once we start coding, we ship one complete piece of the product at a time, front to back. Not “all the screens, half-wired,” but “this one flow, fully working.” A user can sign up. Then: a user can create the one thing the app is about. Then: a user can share it, or pay for it, or whatever the core action is. Each slice is something we could, in theory, hand to a customer the day it’s done.

The payoff is that you’re never more than a couple of days from a build you can actually use, and you never sink a week into plumbing that turns out to feed a feature you cut anyway. When something slips — and something always slips — you lose a feature, not the whole release.

The Friday demo is non-negotiable

Every Friday we show you the real thing: running, on a real device, not a slide deck and not a Figma file. It’s the most useful hour of the week. Seeing the product beats describing it every single time — founders change their minds the moment they tap the actual button, and it’s far cheaper to change your mind in week two than in week six.

It keeps us honest too. A standing weekly demo is a deadline you can’t quietly renegotiate, and it’s remarkable how much invisible, open-ended work disappears once everyone knows there’s a screen to share on Friday.

What we deliberately leave out

Plenty of things that feel essential simply aren’t, for a first version. The usual suspects we park:

• Admin dashboards. You can run the back office straight from the database for a surprisingly long time.
• Settings nobody asked for. Every toggle is a small product you now have to support. Ship opinions, not options.
• A second platform. Pick where your users actually are and win there first. iOS and Android and web is three launches, not one.
• Anything built to impress engineers. Premature abstractions, exotic infrastructure, a microservice for an app with no users. It can wait.

None of this is gone forever — it’s parked, in writing, so nobody feels like it was forgotten. The difference between a six-week MVP and a six-month one is mostly the length of the list you had the discipline to park.

Why the constraint works

A tight timeline isn’t about working faster or longer. It’s a forcing function for focus. It makes you decide what matters before you’ve spent the whole budget finding out, and it gets a real product in front of real users while you still have the time and money to act on what they tell you.

Six weeks won’t hand you a finished company. It hands you the first true thing you’ll learn about your idea — and that beats another month of careful guessing every time.