One core workflow, end to end, and nothing else. That's the answer, and almost every founder reads it, agrees with it, and then builds four workflows anyway — because each individual addition seems small.

Scope is what determines your budget. Not the programming language, not the hosting provider, not the developer's hourly rate. If you want to control what an MVP costs, this is the only lever that moves it substantially. Part of the founder's guide to building an MVP.

Start from the question, not the feature list

Before you rank features, write down what the MVP is testing — the sentence from what an MVP is:

"If ______ happens within ______ weeks of launch, the idea works."

Now every feature gets one question asked of it: does this feature affect whether that outcome happens?

Not "is it useful." Not "will users want it eventually." Almost everything is useful eventually. The question is whether its absence prevents you from learning the thing you're paying to learn.

This is not a scoring framework with weights and a spreadsheet. It's a single binary question, and it's ruthless in a way that scoring frameworks aren't — which is the point, because scoring frameworks let everything through with a mid-range score.

Map the workflow as a sentence

Write your core workflow as one plain sentence with the steps in order.

"A shop owner signs up, uploads their product list, gets a shareable page, and receives an email when someone orders."

Now count the nouns and verbs. Each one is real work: authentication, file upload and parsing, page generation, order capture, email delivery. Five things, each of which has edge cases, error states, and a mobile layout.

That sentence is your MVP. Anything that isn't in it is a candidate for cutting.

The features founders think are small

These come up in almost every project, and every one of them is bigger than it sounds:

Admin dashboard. You will need one eventually. For the first fifty users you can query the database or use a spreadsheet. A real admin panel is its own application — its own screens, permissions, and edge cases.

Notifications. "Just send them an alert" means deciding what triggers it, what the message says, what happens when delivery fails, whether users can turn it off, and where the preference lives. Email is the cheap version. Push notifications on mobile are substantially more.

A second user role. Permissions are not a feature, they're a dimension. Every screen now has two versions and every action needs a check. Adding a second role is closer to a multiplier than an addition.

Search and filtering. Fine over 40 records. A real project once you care about relevance, performance, or combinations of filters.

File and image uploads. Storage, size limits, format validation, resizing, and what happens when someone uploads a 60MB photo on hotel wifi.

Payments. The happy path is a day. Failed cards, refunds, disputes, receipts, tax, and subscription state changes are the rest of it.

Settings and profile pages. Almost pure cost. Nothing about a settings page tests demand.

None of these are hard for a competent developer. They're just work, and work is the thing you're buying.

The three-list method

Take your feature list and sort it into exactly three buckets. Not four — the fourth becomes a hiding place.

Ships in v1. Directly part of the core workflow sentence. If it's missing, the workflow doesn't complete.

Faked in v1. Real to the user, manual behind the scenes. This bucket is where good MVPs are made. Onboarding done over a call. Matching done by you, by hand, every evening. Reports assembled in a spreadsheet and emailed. Invoices generated manually. If you have fewer than a hundred users, you can do an astonishing amount by hand — and you'll learn things automation would have hidden from you.

Not yet. Everything else. Write it down so you stop re-litigating it, and so the developer knows where the product is heading and doesn't build something that blocks it.

If the "ships in v1" list has more than about seven items, you haven't finished cutting.

Cut once more

After you've done that pass, cut again. Founders systematically under-cut on the first attempt, because the first pass removes things you never cared about. The second pass removes things you like, and that's where the real savings are.

Useful prompt: if the budget were halved tomorrow, what would you drop? Whatever you name, drop it now. You've just established it isn't essential — you were only keeping it because you could afford it.

Let the developer cut too

When you brief candidates, ask each one: "If you had to remove 40% of this, what would you remove and why?"

A developer who's shipped a few of these will name specific items and explain which assumption each fails to test. One who says "whatever you prefer" is telling you they'll build exactly what you ask for — which sounds like good service and is how projects end up double the size and double the price.

This is one of the strongest signals in the whole hiring process. How to vet a developer covers the rest.

Write the exclusions down

Your spec should have an explicit "not in this build" section, listing what was cut. This does two things: it makes proposals comparable, and it gives you both a reference when — not if — something resurfaces mid-build.

Without a written exclusion list, every "can we just add…" is a fresh negotiation with no baseline. With one, it's a simple, unemotional conversation about a change request. That's the mechanism that keeps scope creep from quietly eating the schedule you paid for.

What good scope looks like when it's done

• One workflow, written as a sentence.
• Seven or fewer things that ship.
• A written list of what's faked and by whom.
• A written list of what's excluded.
• A success criterion with a number and a date.

Get that on one page and you can hand it to three developers, get three comparable proposals, and have a real conversation about who understood it best. That page is worth more than any other document in the project.

If you want someone to pressure-test a scope before you send it out for quotes, get in touch.