The smallest version of your idea that can be put in front of real users. Built to answer one question, not to be a finished product with fewer features.
Before scoping anything, this is the thing to be clear about. It decides what gets built and what gets left out, and without it every feature seems equally important.
The question worth asking
"What do we need to find out, and what's the cheapest way to find it out?"
Sometimes the answer is an app. Often it's something smaller, and finding that out before spending months building is the most valuable thing this conversation can produce.
The common approach
A full feature list built over months, launched to an audience that hasn't been tested, with the assumptions checked afterwards.
What actually works
One core flow, in front of real users quickly, with the budget for the next version still intact.
The word minimum does the work in that phrase and it's the one people ignore. An MVP is not a cheaper version of the full product. It's a different thing built for a different purpose, and treating it as version one of the real app is how these projects quietly become full builds with a smaller budget.
An example for a marketplace idea. Nothing in the out column is unimportant, it's just not needed to find out whether anyone wants this.
Scoping a first version
Look at the out column and notice how much of it is work you can do manually while you have a small number of users. That's the trick with an MVP: the human doing it by hand is cheaper than the software doing it automatically, right up until it isn't. Building the automation before you have the users is how budgets disappear.
Sometimes you don't need to build anything yet. These are worth trying first, and we'd suggest them even though they're not what you came here to buy.
Describe the product, ask people to sign up, and see whether anyone does. It tests whether the idea appeals before a single screen exists.
AnswersDoes anyone want this?
Deliver the service by hand for your first customers, using spreadsheets and email. Unglamorous, and it teaches you what the software actually needs to do.
AnswersDoes the process work at all?
Off-the-shelf tools connected with automation. Ugly, limited, and often enough to run a real business for six months.
AnswersWill people use it repeatedly?
Screens that look real and do nothing, put in front of potential users. Finds confusion and missing steps before anything is built.
AnswersDo people understand it?
Taking deposits or signed commitments from customers who don't have the product yet. The strongest evidence available.
AnswersWill anyone actually pay?
If your idea works in a browser, start there. No app stores, no approval, no two platforms, and you can change it hourly.
AnswersEverything the app would, faster
We say this on a page selling MVP development because a client who validates cheaply and comes back with evidence is worth considerably more than one who spends their whole budget on a first build that turns out to be aimed at the wrong problem. If one of these gets you the answer, do that instead.
Launching is the middle of the project, not the end. What happens in the following weeks is the entire point of building small.
Week 1
A small group of real users, ideally people you can talk to directly. Ten engaged users tell you more than a thousand anonymous ones.
Weeks 2 to 4
Where they stop, what they ask for, and whether they come back. Coming back is the signal that matters most.
Month 2
Continue, change direction, or stop. All three are legitimate outcomes and the third one saved you a full build.
Then
The next version, scoped from what people actually did rather than what was assumed at the start.
Worth agreeing before you start what result would make you stop. It's much harder to judge fairly once you've spent the money and told people what you're building. Writing it down in advance is the difference between a test and an expensive way of confirming what you already believed.
Three situations where building small doesn't apply, and pretending otherwise causes real problems.
If you're entering a market where established products exist, a rough first version doesn't get a fair hearing. People compare it to what they already use.
Anything medical, financial, or safety related can't ship a version that's deliberately incomplete. The minimum is set by the rules, not by you.
If you're digitising a process you've run manually for years with paying customers, there's nothing left to validate. Build the real thing.
Weeks rather than months, if the scope is genuinely minimal. If it's stretching past a few months, the scope has grown into a full product and it's worth stopping to reconsider.
The timeline is mostly decided in the scoping conversation rather than during the build. Cutting features is what makes it fast.
Some of it, probably, and that's fine. Building for a hundred users differs from building for a hundred thousand, and building the second when you need the first wastes money.
What we avoid is choices that make rewriting harder than it needs to be. Sensible foundations, no clever shortcuts that trap you, and code you own rather than something locked into a tool.
Often yes, and for testing an idea it can be the right call. It's faster and cheaper, and plenty of businesses run on these tools for a long time.
The limits show up with unusual logic, scale, or when you want to move off the platform later. We'd tell you honestly which side of that your idea sits on.
That's a different goal and worth being honest about. A demo built to impress and a product built to learn from are not the same thing.
Most investors are more interested in evidence that people use it than in how it looks. Ten real users who came back beats a polished demo, and it costs less to produce.
You do, on payment. Code in your repository, accounts in your name, and no dependency on us to keep it running.
That matters more with an MVP than with most projects, because the point is to be able to take it in a different direction, possibly with a different team.
Then it did its job, and it did it for a fraction of what finding out the hard way would have cost.
Usually the result isn't a flat no. It's that a different part of the idea was the interesting one, or a different group of users cared more. That's the useful outcome and it only shows up once real people are using something.
Scoped from the question you need answered rather than a feature list. Pricing sits on the main app development page.
Related services
Thirty minutes on the cheapest way to answer it, even if that turns out not to be building anything yet.
Or email hello@culmen.digital