How to build an MVP in days, and keep it when the market says yes

"MVP in days" usually means one of two things. Either a prototype that proves an idea and is thrown away the moment real users arrive, or a genuinely minimal product that is built properly and extended afterwards. The first is cheap and often worthless; the second is what founders actually need. This guide is about the second: how to define a first build small enough to finish in days, decide which parts must be durable, choose how to get it built, and avoid the rebuild that eats the months after a successful launch.

Start from one outcome, not a feature list

Most MVP plans are feature lists trimmed until they look small. That is the wrong direction. Start instead from the single outcome the first version must produce for a user, and build only what that outcome requires.

Write the outcome as one sentence from the user's point of view: "A clinic manager can publish next week's shift schedule and every nurse sees it on their phone." Then list the smallest set of capabilities without which that sentence is false. Anything not on that list is not in the MVP, however obvious it feels. Account settings, billing, admin dashboards, notifications and integrations are nearly always phase two.

This discipline is what makes "days" possible. A first build with one outcome and a handful of capabilities can be scoped on two pages, specified precisely, and delivered quickly. A first build with twelve features cannot, no matter who builds it.

Separate the durable core from the disposable edge

A throwaway MVP is one where everything is disposable. A durable MVP is one where the core is built to last and the edge is allowed to be rough. Deciding which is which is the most important technical decision in the first week.

The durable core is usually:

• The data model. How the central entities relate (accounts, users, the things they create) is expensive to change once real data exists. Get it right, keep it simple, and document it.
• Authentication and permissions. Rebuilding who-can-see-what after launch means migrating real users. Use a proven approach from the start.
• The main workflow. The one path that produces the outcome. It should have tests, because it is what you will change most often.
• Data integrity and backups. Users forgive an ugly screen; they do not forgive lost data.

The disposable edge is usually: visual polish, onboarding flows, marketing pages, reporting, and most settings. These can be plain, manual or missing in the first build.

The rebuild trap happens when the core is built as if it were edge: a prototype data model, a hand-rolled login, a workflow with no tests. It works for the demo, and then the first fifty customers turn it into a liability.

Write the scope in a form that can be priced and tested

Whether you build in-house or order the build, write the first version down as a scope with outcomes, boundaries and acceptance criteria. For an MVP this document is short. It contains:

1. The one-sentence outcome.
2. The capability list (typically five to ten items).
3. What is explicitly excluded, including the things you intend to build next.
4. Acceptance criteria per capability: observable behaviour, required tests, required documentation.
5. Constraints that are real: the stack you must use, the hosting you already have, data-protection requirements.

A scope like this takes a founder an afternoon to write and saves weeks. It also makes it possible to get a fixed price, which matters when runway is finite. The general method is covered in how to write a scope for a fixed-price quote; the startup-specific question of what to include is covered in what to build first when runway is short.

Choose the build route by what it leaves you with

There are four common ways to get an MVP built. Judge them not by how fast they start but by what you own at the end.

Build it yourself. If a founder can write production code, this is the cheapest route in cash and the most expensive in founder time. The risk is that the technical founder becomes the bottleneck for everything, including the parts of the company that are not code.

Hire a first engineer. A long-term decision taken before the product exists. Recruiting and onboarding happen before the first feature, equity is committed early, and if the hire is wrong the runway consumed does not come back. Hiring is better done after the first build, when you know what the product is and can hire for it with evidence.

No-code or a quick prototype. Fast to a demo and fine for testing demand with a landing page or a manual process behind a form. Fragile as a product: the data model and permissions live inside a tool you do not control, and the migration to real software is a second build competing with your first customers.

Order a fixed-price first build. You write the scope, a vendor commits to a price and a delivery, and you receive production code as a tested package with the intellectual property transferred. The cash cost is known in advance. The risk is in choosing the vendor, which is why the engagement should start with a small, real piece of the product rather than the whole MVP. Our engagement works this way: a trial build at a fixed 9,900 euros, delivered within 72 hours of written scope confirmation, with the price deducted in full from the main project; the first three clients receive it for 4,900 euros against a public reference.

What "days" requires from the build process

A first build in days is not achieved by working faster on the same process. It is achieved by removing the waiting from the process.

• Specification before code. The architecture and specification are written first, by one accountable person. Code written before the specification is the main source of rework.
• No calendar dependencies. Reviews, approvals and decisions that wait for a meeting add days. Written decisions, answered within hours, do not.
• Continuous testing. Every change is tested when it is made, not at the end. A test suite that runs with each change is what lets the pace stay high without quality collapsing.
• Staged, visible delivery. A written progress report every day and, at every milestone, a working preview and the code as a package. You see progress without status calls, and acceptance is incremental.
• Work that does not stop at night. A conventional team works business hours in one time zone. A system that builds, tests, reviews and documents in continuous cycles does not, which is where most of the time difference comes from. In our case AIPOS OÜ designs the architecture and specification in-house, agrees them with you in writing, and a multi-agent system then builds against it in 24/7 cycles; 24 hours of its work equals four to eight weeks of a small software company, measured on AIPOS OÜ's own production systems.

Keep it when the market says yes

The point of a durable MVP is that success is not punished. When users arrive, you extend the product instead of rebuilding it. To make sure of that:

• Own the code and the IP outright. The code is handed to you with its full history, the intellectual property is transferred in writing, and nothing essential lives in a vendor's platform. A guide on code ownership when outsourcing lists what to check.
• Insist on documentation. The architecture, the data model and the main workflow are written down, so whoever extends the product next, including a future hire, does not have to reverse-engineer it.
• Insist on tests. The main workflow has automated tests. Every later change runs them. This is what protects the product while it changes quickly.
• Plan the second scope the same way. When the market answers, write the next outcome, scope it, fix the price, deliver it. The method that produced the first build in days works for every build after it.

A founder's one-page plan

1. Write the single outcome the first version must deliver.
2. List the five to ten capabilities without which it fails.
3. Mark which are durable core and which are disposable edge.
4. Write acceptance criteria for each capability and the list of exclusions.
5. Choose the build route by what you own afterwards.
6. Get a fixed price for the first real, bounded piece; judge the result on the preview and in the delivered package before committing to the rest.
7. Hire, if at all, after the first build, with evidence of what the product is.

Founders who follow this plan reach users with a real product, keep their runway for learning rather than rebuilding, and make the hiring decision from a position of knowledge. The startups page describes how the fixed-price route works in detail; the request form is where the scope goes.

Frequently asked questions