Your Product's First Version: What to Build and What to Defer

What kills digital projects is rarely a weak idea or a weak team. It's scope creep: a feature list that grows month after month, and a budget consumed before the product meets a single user. This page is about avoiding that.

MVP does not mean "an unfinished product"

A first version isn't a poor version of the full vision. It's the smallest product that solves a real problem completely for a specific group. The distinction matters: a product that does one thing well gets used; one that does ten things half-well gets abandoned.

Start by naming the core action

Ask: what is the single action that, if it doesn't happen, means the product has failed?

• On a booking platform: the user completes a booking.
• In a store: the user completes a purchase.
• On a classifieds platform: an advertiser posts a listing and hears from an interested buyer.

Anything that doesn't directly serve that action is a candidate for deferral. It's a decisive test that ends long debates quickly.

What can usually wait

• Advanced analytics dashboards. Early on there's barely any data; a simple report is enough.
• Multiple languages. If your first audience is monolingual, launch that way — but design the architecture to absorb another language later without a rewrite.
• Complex permissions. Two or three roles beat a fully flexible role system.
• Automation. Something that happens ten times a day can be done manually at first — and doing so teaches you the right rules before you encode them.
• The app, if the web suffices, and vice versa.
• External integrations, apart from anything genuinely blocking launch, like a payment gateway.

What must never be deferred

• Security and data protection. Retrofitting it is harder and riskier.
• The core data model. Changing it after real users are in is among the most expensive things you can do.
• The primary flow's experience. If booking itself is confusing, no other feature matters.
• Basic measurement. Know at minimum how many users complete the core action — otherwise you're launching blind.
• Acceptable mobile performance.

A simple tool for ordering scope

Put every feature in one of four buckets:

1. Must have — without it the product doesn't function.
2. Should have — important, but there's a temporary workaround.
3. Could have — a pleasant improvement.
4. Won't have for now — explicitly deferred and written down.

That fourth bucket matters most psychologically: recording an idea clearly reassures the person who raised it and stops it returning at every meeting.

Launch, then listen

After launch, users won't tell you directly what they want — but their behaviour will: where they drop off, which feature nobody finds, what they email you about. Two weeks of real usage beats two months of speculation in meetings.

What building our own products taught us

Roshtah is a large platform today, but it didn't start that way. The central idea was that a patient should know their real place in the queue instead of waiting blindly — that's what was built and perfected first. Video consultations, medical records and the clinic admin console came after the core idea proved it was actually used. Building all of it at once would have delayed launch by a year, and half of it would have rested on wrong assumptions.

Have an idea and need its first version scoped? Book a scoping session — you'll leave with a written list of what gets built now, what waits, and why.