Most "MVPs" are not minimum, not viable, and barely a product. They are the founder's full vision with a few features postponed — which is why they take four months, cost a fortune, and still fail to answer the only question that mattered.
A real one-week MVP works. We have shipped several. But the week is the easy part; the hard part happens in the two hours before it.
Start with the question, not the product
Before anything gets designed, write down one sentence:
The single thing we do not know, and that this build exists to find out, is: ______.
Good versions of that sentence:
- "Will home-service businesses actually pay to have their quotes drafted for them?"
- "Will people complete a five-step onboarding to get an accurate result, or drop at step two?"
- "Do restaurant owners care enough about menu QR codes to switch from the free thing they use now?"
Bad versions: "whether people like our app." Not testable, not falsifiable, not useful.
Once the question is fixed, it becomes the referee. Every feature request gets one test: does it help answer the question? Not "is it a good idea." Not "will we need it eventually." Almost everything is a good idea. Almost nothing is needed this week.
The seven things we cut, every time
These come out of the first draft of every scope, without discussion:
- User accounts, unless the thing being tested requires them. A magic link, or no login at all, gets you further than you expect.
- The admin panel. You are the admin. The database is your panel.
- Payments — unless willingness to pay is the question, in which case a payment link is enough. No subscription logic, no billing portal.
- Settings and preferences. Pick the default. It is your product; have an opinion.
- Email notifications. Send them yourself, from your own inbox, for the first few weeks. It is better; people reply to humans.
- The mobile app. A responsive web page tests the idea. An app store review does not.
- Onboarding, tours and empty states. With ten users you can walk each of them through it on a call — and learn ten times more than any analytics dashboard would tell you.
What remains is usually one screen, one flow, one outcome. That is the MVP.
Do the unscalable thing on purpose
The fastest way to ship a complex feature is not to build it.
Your matching algorithm can be you, reading submissions and replying by hand. Your AI report generator can be a good prompt and a human hitting send. Your integration with a legacy system can be a CSV you import each morning with a coffee.
This is not cheating. It is the highest-fidelity user research you will ever get, because you are inside the workflow, feeling every rough edge, discovering that users want something subtly different from what you assumed. Automate it in month two, when you know exactly what you are automating — and when you know whether anyone wants it at all.
The week, day by day
Day 1 — Decide and design
Lock the question. Write the one core flow as a numbered list of steps. Sketch the two or three screens it needs. No Figma polish — a whiteboard photo is fine. End the day with a scope that fits on a sticky note and a plain-English list of what is explicitly not in it. That second list is the one that saves the project.
Days 2–4 — Build the flow
Known stack, known patterns, no new toys. (See how we pick a stack — a one-week build is the least appropriate moment to learn a framework.) Build the happy path first, end to end, before handling a single edge case. A flow that works for the right input beats four half-features that each handle their errors beautifully.
Day 5 — Make it survivable
Now the edges: the empty state, the error message, the mobile layout, the thing that breaks when someone pastes an emoji. Add the minimum analytics needed to observe the answer to your question — usually two or three events, not a dashboard.
Day 6 — Put it in front of humans
Ten real users. Not friends being kind — people with the problem. Watch them use it, in silence, and take notes on the moment they hesitate. The hesitation is the finding.
Day 7 — Read the evidence
Answer the question you wrote on day one. Not "did they like it" — did they do it? Did they come back? Did they pay, or tell someone, or ask when it would be ready?
The trap: the week that becomes a month
It never happens in one big decision. It happens in small, individually reasonable ones:
"While we're in there, we may as well add…"
That sentence is how a one-week MVP becomes a five-week build that answers the same question a week later, having burned four weeks of runway to feel more finished. Keep a "next" list, put every good idea on it, and build none of them. The list is a real deliverable — it is where the roadmap comes from, if the evidence says there should be one.
What "good enough" actually means
A one-week MVP should be rough but not broken. Users forgive an ugly interface and a missing feature. They do not forgive losing their data, a form that silently fails, or a page that hangs. Polish is optional; trust is not.
So: no design system, no animations, no dark mode. But the thing works, it does not lose your input, and when it fails it says so. That is the bar, and it is entirely achievable in five working days.
Have an idea that needs testing, not a spec?
We do one-week MVPs — scoped honestly, built properly, in front of real users by Friday.
Start yours →