What can you actually build in a two-week MVP?

A two-week MVP should let a real user finish a useful task. That might mean booking a consultation, submitting a document or requesting a quote. It should also tell them what happened and make failures recoverable. A prototype can show an idea; a working MVP must cope with real inputs and the essential consequences of its actions.

The schedule depends on scope, access to integrations and timely decisions. Treat two weeks as a bounded delivery plan agreed after discovery, not a guarantee that any application can be completed in fourteen days.

Choose one audience and one problem. A narrow workflow may include sign-in, a small administration screen, a confirmation email and a focused external integration. Each addition needs to serve the same outcome. A complex permissions model, several payment arrangements or a large data migration can change the scope considerably.

Reduce branches before removing essential safeguards. Permissions, validation, clear confirmation and a recovery path belong in the first usable release. Reports, personalisation and alternative journeys can often wait.

A customer-facing MVP might help a founder test whether people will request and book a service without a sales call. Its important measures include completed requests and what stops people finishing. An internal MVP might help a team process incoming documents faster. Its measures include review time, correction rates and unresolved work.

Both need a real owner and representative users. Choose the smallest test that creates useful evidence, and be explicit about any manual work behind the scenes.

Standard patterns for authentication, deployment, storage and monitoring reduce repeated setup work. They still need to be configured for the particular application and checked before release. Reuse should make responsibilities clearer, not hide another customer's accounts, data or assumptions inside the new product.

Use the saved time to refine the core journey. Work through actual examples with the founder, including an invalid input, a service outage and a user who changes their mind.

A short project needs fast answers. Name the person who can decide scope and content, arrange test access to external services and agree the acceptance checks before development starts. An integration that is waiting for an account or approval cannot be made ready by writing more interface code.

Show working increments during the build. A first-week demonstration provides an opportunity to correct a misunderstanding while the change is still small.

Write the idea in two sentences, identify the first users and choose the outcome the MVP should prove. List any existing tools it must connect to and any data it needs to handle. Bring examples of the current process, including where it goes wrong.

A useful brief does not have to prescribe the technology. It needs to explain the business task, the constraints and what you will do with the result.

0 of 5 complete

“Can we just add…” is how a short build expands. When a new idea arrives, ask whether it is necessary for the agreed outcome. If it is, revisit the plan and the trade-off openly. If it is not, record it for a later release.

Launch to the agreed audience, observe what happens and compare it with the original question. The next decision should follow that evidence rather than the size of the feature list.