How to Build an MVP: Steps, Team, and the Real Cost

Most founders ask two questions in one breath: how to build an MVP, and what the cost to build an MVP actually is. The second one usually comes back as a range so wide it is useless — the guides ranking for that query put it anywhere between $5,000 and $150,000. That is not dishonesty. It is an average of projects with nothing in common, and it tells you nothing about yours. So here is the answer I would give a founder sitting across the table from me: the steps that matter, then the money, including the band we publish ourselves.

Skip the definition, keep the constraint

You probably know what a minimum viable product is — if not, we explain it in plain language here. The part worth keeping is the constraint. An MVP exists to test one assumption with real users, and founders usually want one of three things out of it: first revenue, lower operating costs, or a round. Until real people use the product, all of that is a hypothesis with a spreadsheet attached.

That constraint is also your budget control. Anything that does not serve the one assumption is next year's problem, and next year's money.

How to build an MVP, step by step

1. Name the one feature

Write down the single function your product exists to perform. One. A supporting feature or two is fine — sign-in, a list view. By the fourth, you are not building an MVP, you are building a product on a startup's budget.

2. Answer "why you?"

Someone already solves this problem badly. List twenty ways you could do it better, then keep the two a user would notice in the first five minutes. That is the gap between a feature that exists and one worth switching for.

3. Sketch before you design

Paper or a whiteboard. Draw the screens a person walks through to get the value. Most scope arguments happen here if you let them, and they are cheap here.

4. Write down what it must do

A short requirements document: what happens on each screen, and which rules nobody is allowed to bend. If writing it shows you do not know enough yet, that is exactly what a discovery phase is for.

5. Pick a stack you can hire for

Choose technology you can staff a year from now, not the one with the best conference talk. Boring and widely used beats clever every time on an MVP.

6. Build, test, release — then keep going

Test on the devices your users actually hold, not the newest one on your desk. Check registration, login, payments and the core feature until they are dull. Then launch. The launch is the start of the work, not the end of it, and the first two weeks of real usage will teach you more than the previous two months of planning did.

What does it cost to build an MVP?

We publish our own bands on the site, so I will use them rather than invent new ones: a small app or MVP runs $10,000–$35,000 over 4–8 weeks, and a mid-size product runs $35,000–$65,000 over two to four months. Underneath those numbers the arithmetic is dull — hours times rate. The rate depends on where your team sits and is not really negotiable once you have chosen a region. The hours are the part you control.

Three things move them.

Roles. Every distinct user type — customer, admin, driver, doctor — is a separate set of screens, permissions and states. Two roles is not twice one role, but it is a long way from one.

Integrations. Payments, maps, an EHR, a carrier's API. Each one is someone else's system with someone else's documentation, and that is where estimates slip. Count yours before anyone quotes you a number.

Non-functional requirements. HIPAA, offline mode, an uptime promise nobody wrote down until month two. None of it shows up in a demo; all of it shows up in the invoice.

An honest estimate is hours per role against your actual feature list. A vendor who gives you a price before seeing that list is pricing their own risk, not your product — and how you pay for those hours is a separate decision worth making deliberately, because time and materials and fixed price fail in opposite directions.

Two costs founders forget. Mobile carries store review, device fragmentation and a second build if you are not cross-platform — we broke those numbers down separately. And anything with AI in it bills monthly forever: the model calls do not stop when the build does.

One lever genuinely takes hours out of the base. Do not pay anyone to rebuild plumbing — auth, payments, notifications and file storage are the same in almost every product, and we keep a library of prebuilt Node.js microservices so that work is not quoted from scratch on every project.

Who you need on an MVP development team

Fewer people than you would expect:

• one engineer who owns the build and talks to you directly;
• one or two developers alongside them;
• a designer, part-time;
• QA before release, part-time.

You do not need a dedicated project manager or a full-time DevOps engineer for a one-feature product. Five people on a single-feature MVP mostly buy coordination — the meetings grow faster than the software does.

Where MVP budgets actually die

Scope added after kickoff. The estimate covered what you agreed in week one. Every "while we are in there" is a new estimate, and they compound quietly until someone finally adds them up in month three.

Building for traffic you do not have. Architecture for a million users costs like it.

No throwaway decision. Decide upfront which parts are disposable, and say it out loud to the team. An MVP that nobody is willing to delete turns into a legacy system before it has customers, and then you are paying to maintain an experiment.

A slow first screen. People judge an unfamiliar product on how fast it loads, not on the idea behind it. If yours is already live, audit.lomray.com shows what a first-time visitor has to download.

Get a real number for your own list

Ranges from a blog — mine included — are orientation, not an estimate. The useful version takes your feature list, your roles and your integrations and turns them into hours.

Send us yours and you will get an estimate back within 24 hours. If your idea is smaller than you feared, we will tell you that too.