Building
Can you build an MVP in a week? What actually fits
Yes, if it’s one product with one core workflow. What a one-week MVP build can include, what it can’t, and how the scope is set before any code is written.
In short
Yes, if the MVP is one product with one core workflow. A one-week build fits exactly that, done to production standard: sign-in and roles, payments, an admin view, two or three integrations, and the monitoring, backups and deploy pipeline around them. It does not fit several products at once, heavy real-time or offline work, formal compliance programs, or a large migration out of an old system. The scope is cut and written down on a call before the week starts, so nobody discovers on Thursday that it was never going to fit.
Key takeaways
- The unit of a week is one core workflow, not a list of features.
- Production basics — access rules, payments that reconcile, backups, monitoring — are in the week, not after it.
- What doesn’t fit is decided before the week starts, and goes on a written list for week two.
- Bigger products are planned as a series of one-week milestones, each one shipping something usable.
What does “one core workflow” mean?
A core workflow is the one thing your product exists to let someone do, start to finish. For a booking system, it’s a customer choosing a slot, paying a deposit and getting a confirmation — and your staff seeing it on a calendar. For a client portal, it’s a client signing in, seeing their projects and documents, and doing the few things they currently email you about.
Everything a week delivers is organized around that path. Accounts exist so the right person can walk it. Payments exist where the path involves money. The admin view exists so your team can see and fix what happens on it. Features that sit off the path — a second product, a nice-to-have report, a settings page nobody will open for months — are exactly what gets moved to week two.
What fits in a week?
Scoped honestly, most first versions fit. A typical week includes:
- Sign-up and sign-in, including Google, with password reset and sessions that expire properly.
- Roles and permissions — enforced on the server and in the database, not just hidden in the interface.
- Payments or subscriptions through Stripe, with webhooks verified and the failure paths handled.
- An admin view for your team: the records, their state, and the handful of actions you need.
- Two or three integrations with tools you already use — email, your CRM, a calendar, Slack.
- The operational layer: error monitoring, uptime checks, automated backups with a restore that has actually been tested, and a deploy you can roll back.
The same shape holds across product types. A website swaps accounts for a CMS your team edits. A mobile app is built for iOS and Android from one codebase and submitted to both stores within the week — store review then takes as long as Apple and Google take. An AI agent is one assistant with one job, a few tools it can call, and a test set it has to pass.
What doesn’t fit in a week, and why?
Some work is bigger than a week not because it’s hard to type, but because it’s hard to get right and hard to test in five days:
- Several separate products at once. Two workflows means two sets of edge cases, and neither gets finished properly.
- Heavy real-time collaboration or offline sync. Conflict resolution is its own project, and the bugs only show up under real use.
- Formal compliance programs such as HIPAA or SOC 2. We build with strong security practice, but a certification program is an organizational process, not a sprint.
- Large migrations out of a legacy system. The data is always messier than the export suggests, and it needs checking against the original.
None of these are “no”. They are “not in one week” — and knowing that before the week starts is the whole point.
How is the scope decided?
On a scoping call, before anything is paid or built. We ask what the product has to do on launch day, walk the core workflow step by step, and count what it touches: how many kinds of user, whether money moves, how many outside systems it talks to. Each of those adds real work, and a few of them — like moving money without a human approving it — change the size of the job entirely.
You leave the call with a written scope: what is in, what is explicitly out, and a fixed price. The first day of the week turns that scope into a data model and screens you sign off. After Day 1, the scope doesn’t change without a new quote — which is what keeps a one-week build from quietly becoming a three-week one. The full schedule is on the homepage.
What happens when the product is bigger than a week?
We split it into a sequence of one-week milestones. The first ships something real that people can use; each later week has its own fixed scope and price, and you can stop after any of them. That is slower on paper than one big estimate, and faster in practice, because every week ends with working software instead of a progress report.
What should you bring to the scoping call?
- The one thing a user must be able to do on launch day, in a sentence.
- Who the users are — customers, staff, admins — and what each may see.
- Whether money changes hands, and how: one-off payments, subscriptions, deposits.
- The tools it has to talk to, and whether they have an API.
- Any designs or examples you like. Rough is fine.