Your First Version: How to Decide What Ships and What Waits

You have a feature list you wrote yourself, or a developer wrote for you, and a budget that covers part of it. The question in front of you is which part to build first, and on what basis you choose it.

A first version is a risk-reduction tool before it is a shrunken copy of the finished product. You are carrying at least one assumption nobody has tested: that customers will order from the app instead of phoning the branch, that reps will log visits on a phone instead of on paper, that people will pay for the subscription. The first version is the shortest route to finding out whether that assumption holds, before the rest of the budget goes into building on top of it.

The numbers give the point some weight. CB Insights studied the shutdowns of 431 VC-backed companies that closed from 2023 onward, and identified failure reasons for 385 of them. Running out of capital led the list at 70%, but the firm itself describes that as the final cause of death rather than the root problem; the more revealing reason underneath it is poor product-market fit, at 43%. That sample does not transfer to a shop in Tanta or a distributor in Jeddah; these are venture-funded companies with their own conditions. The pattern is still worth noting: the money runs out while something is being built that nobody confirmed the market wanted.

What follows is a sorting rule you can apply to your own list today, the floor you cannot go below however tight the budget is, and the signals that tell you when you are ready to expand.

"Minimum" is not a feature count

The common reading of MVP in the Arab market is "the cheapest, smallest version possible". Eric Ries, whose writing put the term into wide circulation, says the opposite in plain words. In his 2009 guide he defines the minimum viable product as the version that yields a team the most validated learning about its customers for the smallest outlay of effort, then warns in the next line that despite the name, an MVP is not an exercise in building minimal products. In the same passage he adds that it is not a formula at all and takes judgement to work out for any given context. He then gives an example from his own company: IMVU's first MVP took six months to reach the market.

Six months is not a quick version by any measure, and that is the point. The measure is not weeks or screens, but how much you learn against what you spend.

Marty Cagan draws the practical line between "small" and "deficient" more precisely. He defines the minimum viable product as the smallest product with three characteristics: people choose to use or buy it, people can work out how to use it, and you can deliver it when you need it with the resources you have. In a later piece he separates a minimal product from a viable one: the first works and is usable, the second is one people actually choose and that can sustain a business. The distinction, as he frames it, is the difference between asking "could you use it?" and asking "would you use it?".

That is precisely where the risk sits for a business owner: cutting the scope down to something that works technically and that nobody chooses.

Reputational damage comes from the "deficient product" column, and none of it follows from a narrow scope. A good first version does less, and does it completely.

Start from the assumption that would sink the project

Before sorting features, write one sentence: what would have to turn out untrue to leave this project without a point?

For the owner of a small pharmacy chain it might be "the customer will order medicine from the app instead of calling the branch". For a food distributor: "the rep will record the order on a phone during the visit instead of writing it down and keying it in at night". For an education centre owner: "the parent will pay online instead of coming to the office".

Every one of those can be tested with far less than the full product. Ries recounts in a 2009 interview that his team once built a complete feature when a single landing page and an ad measuring whether anyone clicked would have done the job first. He put the lesson this way: not one person would have clicked, so whatever sat on the second page was beside the point.

Not every idea can be tested with a landing page, but the question behind it always works: what is the cheapest way for me to find out I am wrong? Sometimes it is a call with ten customers, sometimes running the service by hand over WhatsApp for a month before any code is written, sometimes selling ten subscriptions in advance. What you learn there changes the list itself, which makes the sorting easier.

One question that sorts your list

Now open the list. Against each item, ask the question the Agile Business Consortium sets out for the DSDM framework under MoSCoW prioritisation: what would happen if this requirement were never delivered? Where the honest answer is that you would cancel the project, because a solution lacking it would be pointless, the item is a must. Everything else is wanted, or waits.

The documentation adds a second test that is harder to be polite about: imagine I come to you the night before launch and tell you this feature will not be ready. Do you stop the launch? If the answer is no, the feature does not belong in the must column, however important it sounded in the meeting.

The manual workaround test

This is the most useful test for an owner who already runs a business, and the documentation states it outright: if there is a way around the requirement, even a manual and painful one, it is not a must for this release.

In Egyptian and Gulf practice the manual route usually exists, and you are already using it today:

• Monthly sales reports: export to Excel and sort them yourself, an hour a month.
• Order status updates for the customer: a WhatsApp message sent by whoever handles orders.
• Returns: a phone call and a paper form at the branch, exactly as it happens now.
• Discount codes: one fixed code you announce and verify by hand on collection.
• Fine-grained per-employee permissions: two accounts and clear responsibility, until the team grows.

Each of these can wait because its absence costs time rather than stopping work. At a hundred orders a day, though, "a manual WhatsApp message" stops being a reasonable workaround and moves into the must column. The rule stays the same while the verdict changes with your size, which is the judgement Ries was describing.

A ceiling on the must-haves

After sorting you will most likely find that everything has become a must. The documentation has a useful line about this: believing everything is a must is usually a symptom of requirements that have not been broken down far enough. "Order management" is not one requirement; inside it sit creating an order, editing it, cancelling it, tracking it and reporting on it, each with a different priority.

The same framework sets a numeric ceiling: must-have effort should not exceed 60% of project effort, with a sensible pool of lower-priority items at around 20%. Going past 60%, the documentation says, introduces a risk of failure unless the environment and technology are well understood, the team is established and external risks are minimal. The logic behind the ceiling is simple: whatever is not a must is your contingency when something slips, and something always slips. A project made entirely of musts is a project with no contingency.

One last rule from the documentation saves a great many plans: a must cannot depend on anything that is not a must. If a feature you classified as essential only works because of a feature you deferred, one of the two classifications is wrong.

The last row is taken from the documentation's own example, and it illustrates a principle many people miss: priority moves over time. Something deferred in the first release may become a must before the project ends. Deferring a feature is not cancelling it.

What never gets deferred, however tight the budget

Your deferral list has a floor. Below it, what you build becomes a deficient product in the sense set out above, and part of that floor is not opinion but written text you can be rejected against.

The stores reject incomplete, not small

If the first version is a mobile app, it goes through a review with published conditions. Apple's App Review Guidelines say under app completeness (2.1) that a submission which is unfinished, or which crashes or shows obvious technical trouble, gets rejected. The minimum functionality rule (4.2) asks for features, content and an interface that lift an app above a website in a wrapper, and 4.2.2 rules out apps that amount to little more than promotional material, clipped web pages, pooled third-party content or a menu of links.

Google Play's policy on functionality, content and user experience takes the same position: apps with only limited functionality and content are not allowed (the example given in the policy text is a text-only or PDF-viewing app), and neither are apps that do not install, or install and do not load, or load and do not respond.

Read the two together. Neither store objects to a short feature list. They object to crashing, to emptiness, and to an app that adds nothing on top of your website. A first version that does one thing and does it reliably gets through; a version that does ten things half-way runs into trouble.

And whatever has no manual workaround at your end

Alongside the store rules, three categories fail the manual workaround test by their nature.

One of them is anything that touches money: taking a payment, recording it, tying it to the order. Mistakes here are not easily repaired later, and you cannot ask a customer to pay a second time because your system did not record the first one.

Another is data you will not be able to reconstruct retroactively. If you do not record which source a customer came from, or when an order changed status, that information is gone and will not return when you need it six months later. Note the asymmetry: recording the data is a must, while the reports built on it can wait months.

A third is whatever a regulator or a statutory system requires for your particular activity. Obligations tied to invoicing, tax or customer data protection are not version-two features; they are operating conditions. Review them with your accountant or legal adviser before you fix the scope, not after.

A fourth category is imposed by no outside body, and it is our professional view rather than a published rule: the shape of your data and permissions. Changing the structure of an orders table after six months of real use costs far more than getting it right in the first week, because the change drags the existing data with it. This does not mean building an elaborate permissions system in version one; it means not building the data in a shape that cannot be extended.

A feature that looks free: accounts and login

Many owners add login automatically, because "every app has a login". Apple's guidelines say something different under data collection and storage (5.1.1): an app without meaningful account-driven features should be usable by anyone who never signs in. And the sentence right after it carries an obligation that almost never reaches the estimate: once an app lets people open accounts, it has to let them close one from inside the app too.

So "a simple login screen" is not one screen. It is registration, verification, password recovery, account deletion, and whatever deletion implies for the data attached to the account. For a first version of a store selling cash on delivery, a phone number with the order may be enough, and the whole account layer can wait until there is a clear reason for it. Apply the same reasoning to the rest of your list: before you classify a feature, ask what it drags along with it.

How to cut without breaking the product

The common mistake when trimming scope is trimming horizontally: keeping every screen and building half of each one. The result looks complete in a presentation and stops at the first real use.

Cut vertically instead. Pick one complete journey for one type of user, build it from end to end, and leave everything else.

Take a hypothetical example: a food distribution company in Mansoura that wants a system for its reps. The one complete journey is that the rep opens the app, sees today's customers, records an order at one of them, the order reaches the warehouse screen, and a warehouse employee confirms it. That chain works end to end and could run tomorrow with five reps. Outside it, everything stays as it is today: cash collection against a paper receipt, returns by phone, reports by Excel export.

This cut works because it leaves you a product that functions within a stated scope rather than a structure full of holes. That is the sense of the principle written into the Agile Manifesto principles: simplicity, described there as the art of maximising the amount of work not done, is essential. Beside it sits another principle worth reading as an acceptance criterion: working software is the primary measure of progress.

Two conditions make the cut succeed:

1. State the boundaries of the scope to the user. "Cash on delivery" written clearly is not a shortcoming; an online payment button that is broken with no explanation is.
2. Give every edge an exit. A contact button or a WhatsApp number wherever a user might need something outside the scope. That button will also become your best source for knowing what to build next.

Knowing when you are ready to expand

After launch, a different question starts: what the second wave should be built on. The easy and wrong answer is "when we have time and money again".

Cagan puts the condition plainly: believing you have reached product-market fit is not enough, and a belief is all most product owners bring to the question; what settles it is evidence. The evidence here is practical rather than emotional.

Repeat use by the same person. The number that matters is how many people came back the following week, not downloads and not sign-ups. Returning is the one thing an ad cannot buy for you.

User sentiment in a measurable form. A question framed by Sean Ellis became common here: out of your active users, what share would describe themselves as very disappointed were the product to disappear tomorrow? Ellis treated 40% as the threshold for product-market fit, but he said in the same passage what most articles leave out: the threshold is admittedly somewhat arbitrary, and he settled on it after comparing results across nearly fifty startups. Treat it as a signal rather than a law, and remember that a percentage calculated over 20 users means nothing.

Usability problems you watched with your own eyes. Nielsen Norman Group reports that a first test with five participants uncovers about 85% of the usability problems in a design, and that three rounds of five beat a single round of fifteen, because the goal is to fix the design rather than document its faults. It adds the line that sums up the matter: zero users give zero insights. Five real customers trying the product in front of you beats any internal argument about the next screen.

The list of repeated requests. After two months of operation you will find three or four requests recurring from different customers. That is your next list, and it came from the market rather than from a meeting.

If those signals line up, start the second wave and re-sort what you deferred by the same rule. Some of what was deferred in the first release is now a must, and some of it nobody asked about in two months, which is itself a result worth counting.

And if the signal points the other way

There is an outcome that deserves to be said plainly: you launch, you fix, you launch again, and the response stays flat. Ries described that moment as the point where, after a number of iterations with no uptake at all, you may tell yourself that you have gone past the minimum viable product, and that this simply is not a viable product.

Learning that after a narrow first version is far cheaper than learning it after a complete one. That is the benefit that makes the sorting worth the effort in the first place.

Once the scope settles

When you have settled what goes in and what waits, other questions start, and they have different answers: how long implementation actually takes, what building the app costs, the steps from idea to store, and whether to buy a ready-made system instead of building at all. Before any of them, turn the scope you chose into a written document agreed with whoever builds it; a scope that is not written down expands on its own during delivery.

One practical habit helps hold the decision in place: tie delivery and payment to stages, against what is actually handed over, as we work at Snaabble. When each payment is attached to a runnable piece, deferring features becomes a clear commercial decision instead of a vague concession.

If you are scoping a system or a digital product at the moment, send your list as it stands to the Snaabble team through the custom systems page. We read it with you and reply within one working day with a view of what deserves a place in the first version, along with an estimate of its duration and cost, at no charge and with nothing owed afterwards.

Sources

All links accessed 20 September 2026.

• Minimum Viable Product: a guide and Eric Ries interviewed by Venture Hacks on what an MVP is, 2009.
• Minimum Viable Product and Viable Product vs. Minimal Product, Marty Cagan, Silicon Valley Product Group.
• MoSCoW Prioritisation, DSDM framework, Agile Business Consortium.
• App Review Guidelines, Apple, sections 2.1, 4.2, 4.2.2 and 5.1.1.
• Functionality, Content, and User Experience, Google Play policies.
• Principles behind the Agile Manifesto, 2001.
• Jakob Nielsen on why five test users are enough, Nielsen Norman Group.
• The sultans of startup marketing, Venture Hacks, November 2009, quoting Sean Ellis.
• The top reasons startups fail, CB Insights.