Why not just build the whole product?

Because you do not yet know which parts of it people want. Building everything spends the entire budget and several months on features that may never be used, and it leaves nothing in reserve for the version you write after real users have told you what was wrong. An MVP is not a cheap product — it is a way of buying information before you commit.

What actually gets cut?

Anything that does not carry the story. In practice that usually means chat, notifications beyond the essential one, social features, multiple user roles, settings screens, and the admin panel. Some of those come back in phase two. Some never come back at all, because once real usage arrives it turns out nobody was asking.

Which features look small but are not?

Live chat, real-time location, payments and any integration with a third party's system. Each of those reads as one line in a brief and lands as weeks of work, because you inherit someone else's rules, someone else's downtime and someone else's edge cases. We flag these at scoping, before they are in the price.

Do I get to change my mind during the build?

Yes, and it is billed. The build is a fixed price against a written scope, with a separate rate for changes. That is not rigidity — it is the only arrangement in which a fixed price stays fair to both of us. Most change requests arrive after the first demo, which is exactly when they are most useful and cheapest to absorb.

Will it be good enough to put in front of investors?

It will be a real app, on real devices, in the stores if you want it there, doing the thing your pitch claims. What it will not be is feature-complete, and that is the point. Investors respond to a working core plus usage numbers far better than to a broad product nobody has touched.

What do I actually own at the end?

The code, the store accounts in your own name, the backend, and a written note on how to run and release it. Nothing about this arrangement should make it awkward to take the project elsewhere or hand it to your own engineers once you have raised.

Mobile & App Development

The smallest version of your product that proves the story

The core of a founder's idea built and shipped in weeks rather than quarters — with the cutting done first, because deciding what not to build is the part that saves the budget.

From: $6,000–$25,000
Typical time: 2–4 months
Usually bought by: Founders

What this actually solves

A founder is short of exactly two things, and neither of them is ideas. Time, because there is a funding conversation or a market window with a date attached to it. And money, because the runway is finite and every week spent building is a week not spent selling. Against those two constraints, building the complete product is close to self-harm — six months and the whole budget disappear into features chosen before anyone knew whether the core proposition worked at all.

What you actually need is the smallest thing that proves the story. Not a mockup, not a clickable prototype, but a real app on a real phone doing the one thing your pitch claims it does — with enough instrumentation behind it that after a month you can say what people did rather than what they said in a survey. Those numbers are the material for your next meeting, and they are worth more than the twenty features you did not build.

Which means the valuable skill in this service is not writing code. It is cutting. Founders arrive with forty features, and the job is to find the handful that carry the story, move the rest into a respectfully named phase two, and be right about which is which. That conversation is the most expensive-to-replace part of the engagement, and it happens before a line is written.

What we do, and in what order

The scoping session, and the list of everything this version will not do. Every feature goes on the table and each is sorted into three piles — the story does not exist without this, this is good and belongs in phase two, and this is a way to spend money at the wrong moment. Every decision gets a one-line reason so you can defend it later. The exclusion list should end up longer than the build list. Two to three days.
Fixed scope, fixed price, and a stated rate for changes. Written down before anything starts, including which parts of the operation will be run by hand at launch and up to roughly what volume that stays workable. Doing the admin manually for the first cohort of users is not a shortcut, it is a legitimate way to buy back three weeks of build time. Two to three days.
Accounts, backend and the skeleton. Store accounts in your name, Firebase or Supabase project, authentication, and analytics wired in from the first week rather than bolted on before the pitch. Three to five days.
Weekly build, weekly demo. Every week ends with something you can open on your own phone and show to someone. This is not a status report — it is the mechanism that catches a wrong assumption in week three instead of week nine. Five to nine weeks.
Real-device testing and the store paperwork. Physical handsets, then icon, screenshots, listing copy, a live privacy policy URL, the privacy and data safety declarations, and a demo login for reviewers. One week.
Submission, review and launch. Both stores, with the review window stated separately in the timeline because that part belongs to Apple and Google. One to two weeks.
Handover, plus the numbers. Code, accounts, backend access, and a short read of what the analytics are actually showing so your next decision is based on behaviour rather than instinct. Two days.

Typical stack — React Native with Expo, Supabase or Firebase for speed, RevenueCat where there are subscriptions, and an analytics layer chosen so the events you will be asked about are being recorded from day one.

What moves the price

The range is $6,000–$25,000 across 2–4 months, taken as a fixed price against a written scope. Three things decide where a project sits in it.

How clear the idea is. A founder who can describe the user, the moment and the outcome in three sentences gets a build that starts immediately. A hazy idea takes roughly twice as long, because the definition work happens inside the project, in increments, while the clock runs.

Whether money moves inside the app. Payments and subscriptions bring store billing rules, receipt validation, refunds, lapsed access and a whole category of states that must be correct rather than approximately right. It is the largest single addition to an MVP scope.

Whether design already exists. A founder arriving with a designed flow shortens the build considerably. Without one, screens have to be designed as they are built, which is workable but slower, and it puts more of the review burden on you.

What usually goes wrong

The scope moves and the price is expected to stay still. Founders are persuasive and often lovely, and somewhere around week three the language shifts to partnership and the idea changes shape. Warm relationship, firm paperwork — a fixed scope with a stated change rate is what keeps both of those true at once. Without it, one budget quietly funds three different products and none of them ships.

The admin panel gets built. It is invisible to users, it never appears in the pitch, and it can absorb weeks. For the first cohort, a spreadsheet and a founder doing the work by hand is faster, cheaper and more informative, because it shows you what the tool actually needs to do before you pay to build it. We name the volume at which that stops being viable so you are not surprised by it.

Analytics are deferred until after launch. The MVP ships, real people use it, and nobody instrumented the funnel — so at the end of the exercise you have opinions instead of evidence, which is precisely what the MVP was supposed to replace. Events go in during the first week, chosen against the questions an investor is going to ask.

See where the site stands before you brief anyone.

If the site is already live, start from what it scores rather than from a guess. The audit reports what it checked, what it found, and — the part most tools leave out — what it could not check, and why.

See the website audit Talk about this work

Questions people ask before they commit.

Why not just build the whole product?: Because you do not yet know which parts of it people want. Building everything spends the entire budget and several months on features that may never be used, and it leaves nothing in reserve for the version you write after real users have told you what was wrong. An MVP is not a cheap product — it is a way of buying information before you commit.
What actually gets cut?: Anything that does not carry the story. In practice that usually means chat, notifications beyond the essential one, social features, multiple user roles, settings screens, and the admin panel. Some of those come back in phase two. Some never come back at all, because once real usage arrives it turns out nobody was asking.
Which features look small but are not?: Live chat, real-time location, payments and any integration with a third party's system. Each of those reads as one line in a brief and lands as weeks of work, because you inherit someone else's rules, someone else's downtime and someone else's edge cases. We flag these at scoping, before they are in the price.
Do I get to change my mind during the build?: Yes, and it is billed. The build is a fixed price against a written scope, with a separate rate for changes. That is not rigidity — it is the only arrangement in which a fixed price stays fair to both of us. Most change requests arrive after the first demo, which is exactly when they are most useful and cheapest to absorb.
Will it be good enough to put in front of investors?: It will be a real app, on real devices, in the stores if you want it there, doing the thing your pitch claims. What it will not be is feature-complete, and that is the point. Investors respond to a working core plus usage numbers far better than to a broad product nobody has touched.
What do I actually own at the end?: The code, the store accounts in your own name, the backend, and a written note on how to run and release it. Nothing about this arrangement should make it awkward to take the project elsewhere or hand it to your own engineers once you have raised.

Often taken together.

Start with the brief, not the invoice.

Send what you are trying to achieve. You get a written scope, a price and a date — or an honest “this is not the right service for that”.

Talk about Startup MVP build All Mobile & App Development services