Guide

From idea to first users: MVP app development in the UK

A minimum viable product is the smallest thing that lets a real person get the one outcome you're promising. Four to eight weeks, £3,000 to £15,000 for most, and its job is to answer a question rather than to be finished.

This is how to choose what goes in, what to cut, what to measure once it's live, and how to avoid the overbuilding that kills most first versions before anyone sees them.

By Lucas Reddington, full-stack developer and AI engineer, Northbytes. Last updated 26 July 2026.

Prototype, MVP, version one

Three different things, routinely used to mean each other, and the confusion is expensive. The word "minimum" does the work in the middle one: minimum features, not minimum quality. An MVP that crashes or loses data hasn't tested your idea, it has tested your ability to ship something broken.

Prototype

days · little or nothing

Clickable screens with no working code behind them. Its job is to answer "does this make sense to someone who isn't you?" before anyone writes software. Show it to ten people in your market and watch where they hesitate.

MVP

4 - 8 weeks · £3,000 - £15,000

The smallest thing real users can genuinely use to get the one outcome your product promises. It has to work properly, be reasonably secure and handle its own errors. It does not have to be complete.

Version one

months · considerably more

What the MVP becomes once real usage has told you which parts matter. Built on evidence rather than assumptions, which is the whole reason to do the MVP first.

What to do before you spend anything

The cheapest week of this whole process is the one before the build, and most founders skip it because it doesn't feel like progress.

Write your idea as one sentence: for whom, doing what, instead of what they do now. The "instead of" is the part people miss. Everybody your product is for is already solving this problem somehow, usually with a spreadsheet, a WhatsApp group or a phone call, and you're asking them to change. That's the bar.

Then talk to ten of them. Not about your idea, which they'll be polite about, but about what they do now and what it costs them in time or money. If they can't describe the problem without prompting, you have found something out for the price of ten conversations rather than for the price of a build.

And check whether the thing already exists. Finding three competitors is good news: it means a market. Finding nothing at all is worth understanding before you assume you're first.

Choosing the features: the one-journey rule

Write down the single journey your product exists for, as a line of steps. A fitness app might be: sign up, choose a programme, log a workout, see progress. That's it. Every feature that isn't a step on that line is out of the MVP, however good it is.

Then apply the second test to what's left: if this feature were missing, would a user be unable to complete the journey, or merely mildly annoyed? Unable, it stays. Annoyed, it waits. Nine times out of ten this cuts a fifteen-item list to five, and the five are buildable in weeks.

Keep the cut list. It isn't a bin, it's the roadmap, and once real users arrive they will reorder it for you in ways you would not have predicted. That reordering is the actual product of an MVP.

Eight things to leave out

These are the features that appear in almost every first conversation, add weeks, and turn out not to matter until much later.

An admin interface

For the first fifty users you can administer the thing directly in the database or a spreadsheet. Building an admin panel nobody outside your team will use is weeks of work at the worst possible time.

Sign in with everything

One sign-in method is enough. Note that if you offer any third-party login on iOS, Apple's rules require Sign in with Apple alongside it, so picking one and not three saves real work.

Payments, sometimes

If you're testing whether people will use it, take payment by invoice or a payment link outside the app. If you're testing whether they'll pay, payments are the point and belong in.

Onboarding flows and tutorials

With your first users you can explain it in person or by email. Onboarding is designed against real confusion you've observed, not confusion you imagined.

Settings and preferences

Every toggle is a branch to build, test and support. Pick sensible defaults and add options when someone actually asks twice.

Both platforms at once

Launch on one platform, or as a web app, and see whether it works before doubling the surface area. Cross-platform makes this cheaper if you know both are coming.

Scaling for users you don't have

Architecture for a million users, built for the eleven you have, is the most expensive form of optimism in software.

Anything you'd describe as "and eventually"

If a feature needs a sentence starting "and eventually it could also", it belongs on a list, not in the build.

One thing never to cut: anything holding personal data still needs proper access control, encryption in transit and a lawful basis for what you're collecting. "It's only an MVP" is not a defence that impresses anybody, least of all the ICO.

A realistic four-to-eight week plan

Week 1: scope and screens. The one journey, the five features, the screens sketched. You sign off on a fixed price and a feature list, and both are written down.
Weeks 2 to 5: build in the open. Working versions in your hands from the second week. You use it as it's built rather than seeing it at the end, which is when most of the useful changes get spotted.
Week 6: real testing. A handful of actual users, not colleagues. Fix what breaks and what confuses; ignore what one person merely dislikes.
Weeks 7 to 8: launch. A web app goes live the day you say so. Mobile adds store submission, so allow a week for review and possible rejection, and don't book a launch event for the day after you submit.

Two things founders consistently underestimate: getting content and photos together, which is your job and always takes longer than the code, and App Store review, which usually passes in a day or two and occasionally comes back asking for something you'll need to fix.

What to measure once it's live

Decide these before launch, because afterwards it's tempting to pick whichever number looks best. Four metrics is plenty.

Activation

What proportion of people who sign up actually reach the thing your product promises, once? If this is low, nothing else matters yet.

Return within a week

For anything meant to be used regularly, this is the honest signal. Downloads and signups are vanity; coming back unprompted is not.

The core action

Pick the one action that means your product worked: a booking made, a workout logged, an invoice sent. Count it per user per week.

Where people stop

The step at which people abandon tells you what to fix next, and it is almost never the step you'd have guessed.

And a number that matters more than all four: how many users you can talk to. At this stage, twenty people you can phone will teach you more than two thousand you can only see in an analytics dashboard.

How we'd approach yours

Bring us a sentence. Genuinely: no spec, no deck, no technical vocabulary. The first conversation is us asking who it's for, what one thing it does, and how you'd know if it worked, and then telling you honestly which of a web app, a mobile app or neither fits. That conversation is free and quite often ends with us suggesting something cheaper than what you asked for.

Then a written scope, a fixed price and a timeline before anything starts. Web apps from £1,500 and mobile apps from £3,000, and you own the code, the designs, the data and the store accounts from delivery. There's more on how that works on the app development page, and the full cost picture is in the app cost guide.

We've done this on our own products as well as clients': The Forge started as a much smaller thing than it is now, and the features it has today were chosen by watching people use the version that didn't have them yet. That is the entire argument for building the small one first.

Common questions

What does an MVP cost in the UK?

A genuinely focused MVP is typically £3,000 to £15,000 depending on whether people log in, whether money changes hands and whether it needs its own backend. Our own starting points are £1,500 for a web app and £3,000 for a mobile app, on a fixed quote agreed before anything starts. If a quote for an MVP is much above £15,000, it is worth asking which features could wait, because it has probably stopped being minimum.

How long should an MVP take to build?

Four to eight weeks from the first conversation to real users, and if it is stretching past twelve, the scope has grown beyond what an MVP is for. The point of the timebox is that you learn something while the assumption you're testing is still relevant. A first version that takes nine months is not an MVP, it is version one with an optimistic name.

Do I need a design document or a spec?

No. Most of the products we've built started as a sentence and a conversation. What genuinely helps is being able to answer three questions: who is this for, what one thing does it let them do, and how will you know if it worked. If you can answer those, we can write the scope with you. If you can't, that's the work to do first, and it costs nothing.

Should my MVP be an app or a web app?

For most MVPs, a web app. There's nothing to install, so people can try it from a link, it's cheaper and faster to build, you can update it several times a day while you're learning, and there's no app review standing between you and a fix. Build a mobile app when the product genuinely needs push notifications, offline use or phone hardware, or when being on the stores is itself the point. Our comparison guide works through it row by row.

Who owns the code if we build an MVP with you?

You do, from delivery: the source code and its history, the designs, the data, and the store or hosting accounts in your own name. That matters more for an MVP than for anything else, because the whole premise is that you might take what you learn and build the next version differently, possibly with someone else. Anything that makes that harder is a supplier protecting themselves rather than you.

Sources

Figures quoted from outside Northbytes come from these sources, checked on 26 July 2026. Our own prices are our published rates.

Want us to do this for you?App Development

Got an idea and no spec?

One sentence is enough to start. We'll come back with a scope, a fixed quote and an honest opinion on whether it should be an app at all.

Get a free quote