How small should your v1 be?

The decision

You're about to write the feature list a builder will quote against. Every line on that list is money — not as a figure of speech, but as hours on an estimate priced at ₹8–30 lakh ($10,000–35,000) agency rates. Over-scoping is the default failure of first builds: it doubles cost and timeline, and it buries the one thing users needed under ten things they didn't. The decision is what earns a place in v1. The honest answer is: almost nothing.

The questions that actually determine it

What is the one job a user hires this product to do?

v1 exists to do one job end-to-end for one kind of user. Not two jobs done adequately — one job done completely, from the user's first click to the moment the value lands in their hands. If you can't state the job in one sentence, no scoping method will save you, because every feature can be argued into a fuzzy mission. When I ran my own SaaS company, the version customers first paid for did exactly one job; the other nine ideas on my original list arrived over the next three years — and several never arrived at all, because nobody asked.

What will you cut when the quote comes back double?

It will. First quotes against first feature lists reliably land at roughly double what the founder had in mind, and the cut happens either now — calmly, on paper — or later, under pressure, with a builder waiting on the call. Deciding the sacrifice order today is free. Deciding it mid-negotiation costs money and judgment.

Which features feel essential because competitors have them?

Parity features are the biggest scope inflators and the least missed in practice. Your competitor built their reviews system in year three, with revenue funding it. Copying it into your day-one quote means paying for their year-three product before your day-one question is answered. Challenge each parity feature individually: has any target user actually said they won't start without it? Usually the answer is no; occasionally it's yes, and then it stays.

What can be manual behind the scenes?

Admin panels, billing edge cases, notification systems, analytics dashboards — the classic v1 line items that a human with a spreadsheet can fake for the first month or three. The user never sees the difference. The quote very much does. Anything that can be manual behind the curtain should be, until volume forces the issue.

Your options, with honest costs and risks

These aren't feature choices; they're scoping postures. Pick one deliberately.

The single-flow v1

One user type, one job, end to end. Everything backstage that can be manual is manual. This is the default posture: the cheapest per unit of learning, the fastest to a real user, the easiest to change. The risk is narrow but real — if your product is genuinely two-sided, a single flow may not be testable at all.

The thin-slice platform

When two-sidedness is the product — a marketplace has no value with one side missing — you build both sides at minimum viable depth. Expect 2–3x the single-flow cost. The risk is that "minimum viable depth" inflates on both sides at once; this posture needs the sacrifice order more than any other.

The full-feature v1

Sometimes genuinely required: enterprise buyers with procurement checklists, regulated flows where the manual-behind-the-scenes trick is illegal. Expect 4–6x the single-flow cost and a timeline measured in quarters, not weeks. The risk compounds: at this size you get roughly one attempt at product-market fit per funding cycle, so the demand evidence has to be strong before you start.

The same idea, scoped three ways

Take a platform connecting parents with verified after-school tutors.

• Single-flow: parents browse a curated list and request a booking. You recruit and verify tutors by hand; payment is a payment link; matching is you and a spreadsheet. Indicative India agency cost: ₹8–12 lakh ($10,000–15,000).
• Thin-slice platform: tutors self-register with profiles, there's a booking calendar, payments happen in-product. Roughly ₹18–30 lakh ($22,000–36,000) — 2–3x.
• Full-feature: apps for both sides, in-app chat, reviews, subscriptions, a referral program, admin dashboards. Roughly ₹35–60 lakh ($42,000–72,000) — 4–6x, before the inevitable change requests.

Same idea. The single-flow version answers the founding question — will parents pay for verified tutors? — at a fifth of the cost of the full-feature version.

What I'd recommend

Don't scope by feel. Use the mechanical method:

1. Put the full wish list on the table. Every feature, uncensored. The method needs the whole list visible — hidden wishes resurface later as "small additions."
2. Tag each item must / should / later, against the one job. If it isn't required for the one job to complete end-to-end, it isn't a "must," however essential it feels.
3. Stress-test every "must": what breaks if a human does this manually for a month? If the answer is "nothing," it moves out of v1. No exemptions for admin panels or dashboards — those are the usual smugglers.
4. Challenge parity features one by one. Each stays only if a real target user has said they won't start without it.
5. Write the sacrifice order down — what goes first, second, third when the quote comes back high — and hand it to your builder as part of the brief. A builder who knows your sacrifice order can protect your budget; one who doesn't will protect the feature list.

If your product is single-sided, build the single-flow v1. If two-sidedness is the product, build the thin slice and be twice as ruthless about depth on each side. Go full-feature only when the buyer's minimum bar genuinely demands it — and verify that bar with an actual buyer, not with your fears.

When this doesn't apply

Enterprise or regulated buyers with a genuinely high minimum bar. SSO, audit logs, data-residency, compliance certifications — some procurement checklists are non-negotiable, and a v1 below the bar simply won't be bought. The method still applies above the bar: verify the bar against a real checklist, scope to it, and not one feature past it.

Products where the wow is the breadth. A few products sell precisely because everything is in one place; a thin slice of an "everything app" demonstrates nothing. These are rare, expensive, and usually need funding to match — know that's the game you're choosing.

Follow-on builds. If you're extending an existing product, scope is constrained by what's already there — integration and consistency costs change the math, and "manual for a month" may break real customers.

If you're in one of these, the small-by-default rule bends. Get an experienced human to pressure-test the scope before you sign a quote.