MVP development: what to build first and what it costs

Most founders do not fail at building an MVP. They fail at deciding what the MVP is not. I have sat through planning meetings where a first release grew from a single screen into a full product with three user roles, two external integrations and an admin panel, and nobody in the room could say why. The scope was never the problem. The refusal to cut was.

An MVP has one job: prove that a real person will use the thing, and come back. Everything else is decoration. If you cannot describe the product in one sentence and the MVP in one screen, you are not ready to build.

Cut the scope before you write a line of code

Here is the exercise I run with founders. Write down every feature you planned. Then delete everything that does not answer a single question: does a real user get value in under two minutes?

For a marketplace, that meant shipping a list page and a contact button, not chat, not reviews, not payments. For a booking tool, it meant a calendar and an email confirmation, not invoicing and not multi-user roles. Those features matter later. They do not matter first.

One founder I worked with wanted a loyalty feature in his food ordering MVP. I asked how many of his first hundred users would refuse to order without points. He admitted none. We shipped the ordering flow in six weeks and added loyalty two months later, after the first paying customers asked for it. That is the whole method in one story.

A rule I find useful: if a feature is not in the first demo you would show a stranger, cut it. You can add it in month two. You cannot get month one back.

The parts you keep should still be built properly. A scrappy MVP is fine. A broken one is not. People forgive a missing feature. They do not forgive a payment that fails or a login that loses their data. Those basics are the one place where "good enough" is a mistake.

What an MVP costs to build

Prices depend on what the MVP actually is. A landing page with a waitlist is a weekend of work. A two-sided marketplace is months. Here are the ranges we see for a first version built by a small senior team:

These are ballpark figures, not quotes. The two things that move the price most are the number of user roles and the number of external integrations. Every extra role roughly doubles the states your product can be in, and every external API is a new place where things break quietly.

One thing I tell founders early: offshore pricing changes the math without changing the quality bar. A team in China can build the same MVP for a fraction of what a local agency quotes, as long as you pick one that has shipped for international clients before. We are based in China and have delivered 300+ projects for clients in Brazil, South Africa, Singapore and the US, across fintech, property, payments, IoT and mini-programs. The working style is the thing we had to get right first, not the code.

Ship something you are slightly embarrassed by

The founders who launch are rarely the ones with the best plan. They are the ones who got comfortable shipping a version that was missing the feature they wanted most. That discomfort is a good sign. It means you cut hard.

Measure one thing in the first month: retention. Do the people who tried it come back on their own? If yes, add the next feature. If no, a nicer design will not save you, and you want to find that out before you spend more. A few hundred users who come back weekly beat ten thousand who signed up once and left.

We have built MVPs that went from a napkin sketch to a live product in under three months, and we have watched founders stall for a year on a spec document. The difference was never budget. It was the willingness to delete.

If you are sitting on an idea and a list of "must have" features, send us the list. The first thing we will do is help you cut it in half.

Talk to us about your project