How to scope an MVP without overbuilding

Most first versions try to do too much. The founder has been thinking about the product for months, the feature list has grown to three pages and every item on it feels necessary. Then the build takes twice as long as planned, the budget runs out before launch and nobody outside the team ever uses it.

A first version is a bet on what people will pay for. The smaller the bet, the sooner you find out whether you were right. This is how we help clients decide what goes into a first release, with the decisions we made on PSC Mocklab, a mock-test app we built for Mathematica LLP, as the worked example.

Start with one sentence

Before the feature list, write one sentence that says who your users are, what problem they have and what the product does about it.

For PSC Mocklab the sentence writes itself from the brief: Kerala PSC aspirants study from scanned Malayalam question papers they can’t search or practise against, and the app turns those papers into questions they can practise one topic at a time.

Every feature then gets measured against that sentence. If it doesn’t help the user in the sentence with the problem in the sentence, it waits, even when it’s a good idea. Good ideas cause most of the overbuilding, because nobody has to argue for the bad ones.

Sort every feature into one of three lists

Go through the feature list and put each item in one of three places.

Must have

Without this, the user in your sentence can’t get the result in your sentence. For a mock-test app that’s the questions, a way to practise them and a way to see how you did.

Can wait

Useful, maybe already planned, but the first users won’t notice it’s missing. For PSC Mocklab that list included a daily live quiz, promo codes for specific plans and onboarding questions that personalise practice. All three are being built now, after launch, and none of them would have changed whether the core idea worked.

Do by hand

Things that have to happen but don’t need software yet. Approving a refund, answering a support message, loading the first batch of content. A person with a spreadsheet can do a surprising amount of a product’s job for the first few months, and watching them is the best way to learn what the software should eventually do.

Build one journey from start to finish

An MVP needs to do one thing well. Map the single path a user takes from opening the app to getting the result, and build that whole path before anything else.

In PSC Mocklab the path is short. Pick a subject, work through a sublesson, then take a Full Lesson Test that pulls together the questions from every sublesson in the lesson. Scores go to a leaderboard, and a subscription unlocks the full question bank. Everything in the first release either serves that path or protects the subscription that pays for it, such as keeping paid accounts to one device at a time.

The decisions that kept it small

Scope isn’t only a list of features. The technical decisions set how much there is to build and then run, and on PSC Mocklab three of them did most of the work.

The first was to run no application servers at all. The audience is price sensitive, so running costs had to stay close to zero until usage grew. Clerk handles sign-in, Supabase holds the data and Razorpay takes payments. The only custom backend code is a handful of small Supabase Edge Functions, which cost nothing when nobody is using the app. There was nothing to provision, patch or watch for the first release, and there still isn’t.

The second was to generate content in advance. Turning scanned pages into questions with Gemini is the most expensive work in the product, and it never happens while someone is using the app. Learners only see questions that were generated, reviewed and stored ahead of time, so the cost per user stays flat and a rate limit on the AI side can’t reach them.

The third was to start from something that had already run in production. The app began as a fork of Chatterbox, an English-learning app we built for a client, so sign-in, payments, admin tools and the release setup were already proven. None of that had to be designed or debugged for the first release.

More than 400 users enrolled in the two weeks after launch. The case study covers the content pipeline and the architecture in more detail.

Decide what you’ll measure before you launch

Pick the two or three numbers that would tell you the bet is paying off, and make sure the first release records them. For most products that’s some mix of sign-ups, how many people come back in the first week and how many pay.

It’s tempting to leave analytics for later because nobody will see it. Then the launch happens, the first users arrive and you have opinions instead of numbers. The next round of work should follow what people do in the product, and you can only see that if you were counting from day one.

Leave room for what comes next

A small first release still needs a foundation that can grow: well supported tools, a sensible data model and a clear split between the parts that will change and the parts that won’t.

On PSC Mocklab, when the questions in a sublesson change, database triggers rebuild the Full Lesson Test for that lesson. New content needs no release and no background job. That kind of decision is cheap to make at the start and expensive to retrofit.

Design the data model so the next few features fit. Then stop. The features themselves can wait for the numbers.

What a one-page scope looks like

That page has six parts:

1. The sentence: who, what problem, what the product does about it.
2. The journey, as a numbered list of steps.
3. The must-have features, each tied to a step in the journey.
4. The can-wait list, so good ideas have somewhere to go that isn’t the first release.
5. The do-by-hand list, and who does each thing.
6. The two or three numbers you’ll watch after launch.

Add one line for the biggest technical decision, such as whether you’ll run servers at all. If you can’t write that line yet, it’s worth a conversation before the build starts.

How this works with us

Scoping is the second of the five stages in how we take a project from problem to production. We start by understanding the business and the problem, then work through the lists above with you. Before any build work starts, you get a proposal with the plan, a timeline, a cost estimate and the engineer who will lead the project. There’s more on what that looks like on our MVP development page.

If you have a first version in mind, send us your one-page scope, or whatever notes you have so far. You don’t need a finished specification.