Freelancer, no-code or agency: who should build your app?
10 min read
Key takeaways
- An MVP is not a degraded version: it is a complete version of a smaller scope.
- Keep a single user journey from end to end, and make it perfect.
- Never cut authentication, error handling or usage measurement.
- A feature useful to fewer than 20% of users waits for version 2.
- A manual back office is a far better use of time than three weeks of automation.
Every project starts with the same scene. A list of forty features, all "essential", and a budget that allows ten. The reflex is to keep everything and do it less well. It is the only strategy that fails for certain.
An MVP is not a half-finished product. It is a finished product on a reduced scope. Users see the difference immediately, and it decides everything.
The single-journey test
Ask yourself one question: which journey, if it works perfectly, proves that the product has value?
For a booking app, it is: I find a slot, I book, I receive a confirmation. Not cancellation management, not the loyalty programme, not social sharing, not statistics.
This journey becomes your backbone. Anything that does not contribute to it directly goes into version 2. No exceptions, no discussion.
The rule that unlocks every trade-off: a feature goes into the MVP if its absence prevents the main journey from being completed. If the journey can be completed without it — even less pleasantly — it waits.
The four things you should never cut
They do not show on a mock-up, they cannot be sold in a meeting, and cutting them destroys the MVP.
1. Proper authentication. Creating an account, signing in, resetting a password, signing out. Botching this part loses 30 to 50% of users before they even see the product.
2. Error handling. Network down, server unavailable, invalid input, expired session. A user who sees a blank screen does not come back, and will never tell you why.
3. Usage measurement. Without analytics, your MVP answers no questions. You will have spent the budget and still not know whether it works. Three well-chosen events are worth more than thirty badly placed ones.
4. A user feedback channel. A "report a problem" button that sends an email. One day of development, and it is your best source of information for the first three months.
The six cuts that save the most time
| What you cut | What you do instead | Typical saving |
|---|---|---|
| Administration back office | Direct database access for the team, or a spreadsheet-style connected tool | 2 to 4 weeks |
| Segmented push notifications | A simple transactional email | 1 to 2 weeks |
| Full offline mode | A clear "connection required" message | 2 to 3 weeks |
| Five-screen onboarding | One screen, then contextual help | 1 week |
| Fine-grained roles and permissions | Two roles: user and administrator | 1 to 3 weeks |
| Integrated payment | A link to an existing payment page | 1 to 2 weeks |
The first point deserves emphasis. The back office is the most underestimated item and the easiest to put off. As long as you have fewer than a few hundred users, a manual operation done by one person on the team costs infinitely less than automating it. Automate when the pain becomes real, not when it is theoretical.
Prioritisation in a workshop, in practice
We work in three rounds, over two hours.
Round 1 — Everyone writes. Each participant lists the features they consider essential. No discussion, no filter. You typically get 40 to 60 items.
Round 2 — The journey filter. For each item: "can the main journey be completed without it?" If so, the item is out. Usually 12 to 18 remain.
Round 3 — The 20% filter. For each remaining item: "what proportion of users will use it in the first week?" Below 20%, the item is out. 5 to 8 remain.
That is your MVP. The rest is not lost: it forms the roadmap, prioritised by data rather than by how loudly participants speak.
40 → 6Typical scope reduction after three rounds of prioritisation
8–14 weeksRealistic duration of a mobile MVP, scoping and publication included
≈ 50%Of the features set aside that turn out to be unnecessary
The trap of the MVP that is no longer one
The scope always overflows in the same way: through small, reasonable additions. "While we're at it", "it's just one more field", "the client asked for it". Each costs a day; fifteen of them cost a month.
The remedy is simple and a little brutal: any feature added during the MVP must replace another one, at constant budget. This rule transforms discussions instantly. What was "essential" becomes negotiable again as soon as something else has to be sacrificed.
An MVP that is three months late is no longer an MVP: it is a badly budgeted version 1, delivered late, with the flaws of both approaches.
After launch
Measure for four to eight weeks before deciding anything. Three figures are enough: how many people complete the main journey, how many come back the following week, and exactly where the others drop out.
These three figures are worth more than all the prioritisation workshops in the world — and they cost far less. To place the overall budget of an MVP within a whole project, our article on the cost of a mobile app details the budget tiers.
