MVP development: ship less, learn faster

Everyone has heard "ship an MVP," but few teams actually do it. What usually ships is a full product with a few features cut at the last minute, plus a promise to trim later. That is not an MVP. It is a small version of the final thing, and it costs almost as much as the final thing.

An MVP is the cheapest thing you can put in front of real users that teaches you something you did not already know. Everything else is scope creep wearing a startup t-shirt.

Start from the one question

Before you write a line of code, write down the one thing you need to learn. It is usually a yes or no question:

• Will people pay for this?
• Can a restaurant run a lunch service on this POS without a manual?
• Does the partner actually use the dashboard we imagined?

If the answer is already obvious, you are not building an MVP. You are building a product and calling it an MVP to feel disciplined.

How to cut it down

Once the question is clear, the feature list gets easy to cut. The rule we use with clients is blunt: if removing a feature does not change what you learn, cut it.

A few cuts that almost always work:

• Admin panel. Ship with a spreadsheet and a few SQL queries first. Build the panel when the first operator complains.
• Notifications. Email is fine for six months. Push can wait.
• Social login. Email and password first. Add Google and WeChat login when users ask for it.
• Reporting. Export a CSV and let the client's finance team handle it.

What it costs and how long it takes

These ranges are for a small team building in a modern stack. They vary because the product is the variable, not the vendor.

The two-sided MVP is where budgets die. Two roles means two apps, an admin view, and reconciliation between them. If you can fake one side manually at first, do it.

The mistakes that inflate an MVP

A few things quietly turn a small MVP into a long build.

• Building for scale on day one. A queue system, a Kubernetes cluster, and a microservices split are all fine later. On an MVP with five users, they are pure overhead.
• Designing every screen in the tool before testing one. Prototype with real users first. Polishing an unused screen is the most expensive work in the project.
• Letting a stakeholder add "just one more field" each week. Small additions compound. Write the scope down, and treat anything new as a phase-two item with its own cost.

The common thread is that none of these are technical problems. They are decision problems, and they get cheaper to fix the earlier you catch them.

Sometimes the MVP is not custom code

Before you commission a build, check whether an off-the-shelf tool plus a bit of glue gets you to the same learning faster. A no-code form builder, a Shopify store, or a spreadsheet-driven workflow can validate a lot for a tenth of the cost.

The point of the MVP is the question, not the software. If you can answer the question with a $500 tool, answer it with the $500 tool and save the custom build for what survives. We tell clients this openly, even when it means we build less. The trust it creates pays off on the second project.

The part people skip

Validation is not the launch. Most MVPs we see die in the month after launch, not in development. Plan the first thirty days: who you will show it to, what they will do, and what counts as a good enough signal to keep building.

One specific suggestion: agree on a kill criteria before launch. Something like, "if ten restaurants trial it and fewer than four stay past the first week, we stop." Writing that down now saves you three months of polishing a thing the market already rejected.

We build MVPs for startups and for established companies testing a new line of business. The overlap-hours setup means a founder in São Paulo or Cape Town can review a build in their afternoon and have changes by morning. It keeps the loop short, which is the whole point of an MVP.

Talk to us about your project