An MVP in one week: what actually fits in five working days

Someone always asks whether an MVP can be built in a week, and the answer is genuinely yes, with a condition attached that most of the conversation skips. A week buys you one complete path through a product. One user, one job, start to finish. It does not buy you a small version of the product you have in mind, because the thing you have in mind almost certainly has four paths in it.

The useful discipline is not working faster. It is knowing in advance which parts of a build are effectively free now and which parts still cost days, because that ratio has changed a lot and most plans are still priced on the old ratio.

What one week actually means

Five working days, one or two people, and no pre-existing codebase. That is the version of the question worth answering. It is also worth being blunt that the week does not start when you open the editor. It starts when the decisions are made, and if the decisions are still open on Monday morning you do not have five days, you have three.

This is the same failure described in scoping a software project before anyone writes code. A one week build is simply the case where the cost of a vague scope is impossible to hide, because there is no slack anywhere to absorb it.

The parts that are close to free now

Two of the historically expensive pieces of any application are now configuration rather than construction, and this is the single biggest reason a one week MVP is realistic at all.

Authentication is the first. Firebase Authentication's documentation covers email and password, phone number, anonymous sessions and federated sign-in with Google, Apple, Facebook and GitHub, and it makes the argument for not rolling your own directly: it handles "edge cases like account recovery and account linking that can be security sensitive and error-prone to handle correctly". Those edge cases, not the login form, are what used to consume the days.

Payments is the second. Stripe's Checkout documentation describes a hosted full page option it rates as low complexity with fifteen configurable brand settings, against an Elements integration it rates as the most complex with full CSS control. Same payment capability, and Stripe documents support for more than 125 local payment methods behind it. The hosted page is the one that fits in a week, and the choice between them is a genuine fork: you are trading visual control for days.

Read the last row carefully. Nothing about faster infrastructure made the domain logic cheaper. It made everything around the domain logic cheaper, which means the domain logic is now almost the entire cost of the week rather than a portion of it.

What fits: one path, end to end

The version that works is a single complete journey. A user arrives, does the one thing the product exists to do, and something real happens at the other end. If it is a booking tool, one service gets booked and one confirmation goes out. If it is an internal tool, one record goes in and one report comes out.

• One user type. Not an admin and a customer, one of them.
• One happy path, with the obvious failure states handled and nothing else.
• Real data, entered by hand if necessary. Seeded fake data hides the problems you built this to find.
• One way in. Skip the marketing site, the onboarding tour and the settings page.

The temptation is to add the second user type because it seems small. It is never small. A second user type doubles the permission surface, the navigation and the test matrix, and it is the most common reason a one week build becomes a three week build.

What does not fit, honestly

Some things cannot be compressed into the week and pretending otherwise is how the deadline gets missed on Thursday afternoon.

• Anything requiring a third party to approve you. Payment account activation and business verification run on somebody else's calendar, not yours, so start them on day one rather than day four.
• Data migration out of an existing system. The import is never the problem. The four years of inconsistent records are the problem.
• Integrations with an API you have not read yet. Budget the reading separately, or it lands mid-week as a surprise.
• Anything with a compliance review attached to it.

If your idea has one of those at its centre, the honest answer is that a week produces a convincing prototype rather than a working product, and the two are useful for different things. Honest ranges for building a web app covers what the realistic number looks like once one of these is in scope.

Should it be code at all

For a genuine one week test, the question of whether to write software is still open. A no code tool will often get the same learning faster, and the point at which that stops being true is specific rather than philosophical, which is the subject of where no code stops. If the week exists to find out whether anyone wants the thing, the cheapest instrument wins and it is frequently not a codebase.

The case for building is when the thing you need to learn is about the mechanism rather than the demand. If the risky part is whether the calculation is right, or whether the workflow survives contact with a real operator, a prototype has to actually run.

How to know whether the week worked

The test is not whether it shipped. It is whether it answered the question you built it to answer, and that means writing the question down before Monday. "Will operations staff use this instead of the spreadsheet" is a question a one week build can answer. "Is this a business" is not.

A build that ships on Friday and teaches you nothing is the expensive outcome, because it usually gets extended rather than discarded, and an MVP that gets extended without ever being validated becomes the codebase everyone regrets in a year. That path is described from the other end in why software projects take so long.

It is also worth remembering what the week does not settle. A working product and a product anyone will pay for are separate problems, and the second one has its own methods. Our colleagues at BDG Labs wrote a practical piece on where the first B2B customers actually come from, which is the work that starts the Monday after.

The honest limits

A one week MVP is a real technique with a narrow purpose. It is excellent for resolving a specific uncertainty quickly, and poor at almost everything else. It will not be secure enough for regulated data, it will not survive a load spike, and the code will contain decisions you would not defend in review. All of that is acceptable in exchange for the answer, and none of it is acceptable if the thing quietly becomes production.

The most common mistake is not building it too fast. It is failing to decide in advance whether Friday's output is a throwaway or a foundation, because that decision changes how you build on Tuesday and it cannot be made retroactively.