What counts as an MVP, and how is it different from a prototype?

A prototype is something to look at and click through: nothing behind it is real, and it is thrown away once it has answered its question. An MVP is working software with real users, real data and, if you charge, real payments — it is just deliberately narrow. A first version is what an MVP becomes once you keep building on it. The test is not how many features are in it. It is whether one kind of user can complete the one thing the product exists to do, end to end, without someone filling the gaps by hand.

How do you decide what goes in and what waits?

We start from the single path that has to work — what a user follows from signing up to getting the thing they came for — and everything on that path goes in. Everything beside it waits: extra roles, admin screens a spreadsheet can cover for now, settings nobody has asked for, the second payment method, the analytics dashboard. Two questions settle most of the argument. Does the product fail without it? And can it be done by hand for the first few weeks without embarrassing anyone? What survives both goes into the scope, in writing, before the build starts.

Does the MVP code get thrown away later, or does it become the real product?

It becomes the real product, and we build it that way: the same language and framework we would use for a full build, tests around anything touching money and data, database migrations from the first week, one command to deploy. An MVP cuts scope, not engineering. The shortcuts we do take are visible ones — a hosted service instead of something built in-house, an admin screen that is plain rather than designed, a manual step behind a button — and each is written down with what it will cost to replace. It is the invisible shortcuts, like untested payments or a database with no way to evolve it, that force a rewrite six months later.

You do. The repository is yours from the first commit and stays yours whether we continue together or not. The same goes for the hosting accounts, the domain, the database and any third-party services opened for the product: they are set up in your name, not ours. There is no proprietary framework to license and nothing that has to be transferred later.

What happens when the idea changes mid-build?

It usually does, and that is part of why you are building an MVP rather than the whole thing. Small changes go into the current sprint by taking something else out of it, not by quietly moving the date. Anything larger gets a written estimate of cost and schedule before it is built, and you decide. What we ask in return is that a change is a decision and not a hesitation: putting a feature in and pulling it out repeatedly costs more than either version of it. Every accepted change is tracked against the original written scope, so at the end you can see what you actually bought.

How long before we have something people can use?

We do not give a number before we know the scope, because the honest answer depends on things we have to see first: how many kinds of user the product has, whether it needs payments and through which provider, whether it has to connect to systems you already run, whether the design exists or still has to be made, whether the app stores are involved, and how fast decisions come back from your side — that last one moves the date more than anything technical. What we do commit to is dated milestones written down before development starts, and software you can log into at the end of every sprint, so you are never waiting until the end to find out where the project stands.

What does an MVP cost?

The cost follows the scope, so we size the work before quoting rather than after. Two models: a fixed price against a written scope when the first release is clear enough to fix, or a monthly rate when priorities will keep moving — which is common for a product that has not met its users yet. The band we work in for an app or an MVP build is published on the What it costs page instead of being kept back for a call. The scoping conversation that produces the estimate costs you nothing.

What happens after launch?

Defects against the agreed scope are ours to fix, not a new invoice. Beyond that, the useful work is reading what the first weeks of real usage told you, which is why we instrument the main path before launch rather than after — so there is something to read. From there you either keep us on for the next release and maintenance, or take the documentation, the deployment pipeline and the running product and continue with your own developers. We run our own product, Dextra, a coaching web app with real users, real coaches and real payments, so what happens after launch is not a theoretical question for us.

MVP development

MVP development, built to survive success.

We build MVPs for web and mobile: the smallest version of your product that real users can actually use, built so the next six months extend it instead of replacing it. Nearshore from Tunis for companies in Europe and North Africa.

Scope an MVP Our approach

Approach

How we do it.

A scope you can read

Before anything is built: the user, the one job, the screens, the data, and what is explicitly not in version one. It is the document the estimate is attached to, and it changes by decision rather than by drift.

The riskiest part first

The payment, the integration, the matching, the calculation — whatever decides whether the product works at all is built before the parts everyone already agrees on, while there is still budget to react to the answer.

A real product, not a prototype

Real accounts, real data, real payments where money moves. Something a stranger can use without you sitting next to them, because that is the only way an MVP produces evidence instead of opinions.

Sprint demos

Working software at the end of every sprint, so you steer with what exists rather than with a status report. When the scope changes the estimate changes, in writing, before the work starts.

Foundations that are not cut

Migrations, environments, backups, error tracking, and tests around authentication and money from the first week. Shortcuts are taken where they are cheap to undo, and nowhere else.

Yours from the first commit

The repository, the cloud accounts, the domains and the store accounts are in your name. Continuing with us should be a choice, never a dependency.

In detail

What to know before you start.

01Definition

What an MVP is, and what it is not.

A minimum viable product is the smallest thing you can put in front of a real user that lets them finish a real job, and that gives you evidence about whether the idea works. Minimum refers to scope. Viable refers to quality. Most failed MVPs got those two the wrong way round.

It is not

A prototype. A clickable design tells you whether people understand a screen. It tells you nothing about whether they will use the product, pay for it, or come back on Tuesday.
A demo for investors. That is a different artefact with a different budget, and confusing the two produces software that works only when you are the one driving it.
A cheap version of the whole product. Removing the polish from thirty features gives you thirty bad features. Cutting to three good ones gives you a product.
A throwaway. MVPs that work get extended, not rebuilt — which is exactly why the foundations are the wrong place to save money.

It is

One user, one job, one complete path through the product, done properly end to end.
Real enough to charge for, when charging is part of what you are testing.
Instrumented, so what happens is measured rather than remembered.
Written so that the next six months of work extend it instead of replacing it.

Every decision in an MVP answers the same question: what do we need to learn next, and what is the smallest real thing that teaches it.

02Cutting scope

Cutting scope without cutting quality.

There are two ways to make a build smaller. One is to do fewer things. The other is to do the same things worse. Only the first one works, and the difference between them is the whole craft of building an MVP.

Cut freely

Features that serve a user you are not testing yet. The second segment can wait until the first one is proven.
Configuration screens. A setting that three customers need can be changed by your team directly until there are thirty.
The designed admin interface. A generated back office or a handful of internal pages is enough while the data model is still moving.
Integrations that are nice rather than necessary: exports, third-party sync, enterprise single sign-on for companies you have not signed.
Edge cases nobody has actually seen. Handle them visibly and by hand until they happen.
Extra languages, extra platforms, extra channels. Being properly on one is enough to learn from.
Anything that only matters at a scale you do not have. You can add a cache the week you need a cache.

Do not cut

Authentication, session handling and server-side permission checks. This is the one category of bug that ends a product rather than annoying a user.
Correct handling of money: idempotent operations, webhooks that can be replayed safely, and a record you can reconcile against the provider.
Database migrations from the first commit, so the schema has a history and every environment matches.
Backups — with a restore that somebody has actually performed at least once.
Error tracking and enough logging to answer what happened. Flying blind is not a saving.
A data model that can represent the truth. Wrong data is expensive to fix later and sometimes impossible.
The basics of privacy: collect less, say what you collect, and be able to delete it when asked.
Keyboard access and readable contrast. They cost nothing when built in and become a project when retrofitted.

The line is simple enough to apply in a meeting. Cut what is expensive to build now and cheap to add later. Keep what is cheap now and expensive to repair.

03What first

What to build first, and what to defer.

Every product idea rests on one assumption that decides everything, and it is rarely the one the plan opens with. It might be whether people will pay, whether an integration is even possible, whether a calculation can be trusted, or whether supply exists on the other side of a marketplace. Build that first, while there is still budget left to act on the answer.

The order we use

Name the assumption that would kill the product if it turned out to be false, and decide how the build will test it.
Build one complete path — from sign-up to the moment of value — rather than several half-finished areas. Nobody can use half of three flows.
Put the hard part on the critical path early. The integration that might not work is not a task for week eleven.
Replace what a person can do with a person. If a human can do the matching, the moderation or the onboarding by hand for the first users, that is a feature you have not built and a process you now understand properly.
Instrument before launch. Decide the number that means continue and the number that means stop, and make sure you can see it on day one.

What gets deferred is written down with the reason, not forgotten. That list becomes the start of the roadmap, and it stops the same argument being had twice in three months.

04Evidence

Proving the idea with the smallest real thing.

An MVP exists to produce evidence, and evidence needs a real person at the other end. Ten users who arrived from somewhere and did something are worth more than a hundred demo accounts and a good meeting.

One channel and one segment. If you cannot say where the first fifty users will come from, the build is not your bottleneck.
A launch that is narrow on purpose: an invite list, one city, one partner, one category.
Payment early, if the product is paid. Willingness to pay is the only reliable signal, and free users tell you very little about a paid product.
A small number of measured events — activation, the core action, repeat use, payment — instead of an analytics dashboard nobody opens.
A direct line to the first users. The first weeks are conversations, not tickets.

The plan leaves time for that. An MVP that spends its entire budget before launch has bought a piece of software and skipped the part that was supposed to make it worth something.

05Dextra

What this looks like: Dextra, our own product.

Dextra is our own product — we designed it, built it, and we run it. It is the honest reference for how we work, rather than a story about somebody else's project.

A fitness coaching web application, live at dextra.fitness, in Arabic, French and English — which makes right-to-left layout a first-class case rather than an afterthought.
Real users, and certified coaches delivering programmes through it.
Real payments through Flouci and D17, the providers people in Tunisia actually use, including the reconciliation, retry and support work that arrives with money.
Mobile applications on the App Store and Google Play, alongside the web application.

It was built the way this page describes. Web first, because a web application reaches everyone immediately and does not wait in a review queue. One complete path, from sign-up to a paid programme, before anything else was widened. Local payment providers rather than a card gateway the market does not use. Mobile applications only once the product had earned them.

Operating it is the part that teaches the most: support, upgrades, failed payments, real users on inexpensive Android phones and slow connections. That is a different kind of knowledge from shipping something and leaving. There is more detail on the Dextra project.

06After the MVP

From MVP to production system.

If the MVP works, the pressure changes shape. More users, more roles, more edge cases, and a team that now has to support the thing while continuing to build it. Very little of that work is about rewriting code.

Operations: real monitoring and alerting, an incident path, and reporting your own team can run without asking a developer.
The internal tooling you deferred: proper admin screens, permissions, and an audit trail of who changed what.
Performance where it now matters: indexes and query plans against real data volume, caching, background jobs, pagination that survives a large account.
The deferred list, revisited with evidence. Some of it turns out to be unnecessary, which is precisely why it was deferred rather than argued about.
Compliance and contracts as customers get bigger: data processing terms, retention rules, export and deletion, the security questionnaire that arrives with procurement.
Test coverage extended around whatever has broken, because incidents tell you where the tests should have been.

That is a series of deliberate increments on the same codebase. If it can only be done as a rewrite, the MVP was built wrong — which is what the next two sections are about.

07Technical debt

Debt that is acceptable, and debt that never is.

An MVP is supposed to carry debt. Debt is a loan against speed, and speed is the entire point of an MVP. What matters is which loans can be repaid and which cannot.

Acceptable at this stage

No admin interface. A script and a database client, used by someone who knows what they are doing.
Manual operations. A person doing by hand what will later be automated, with the steps written down.
One region, one server, no autoscaling. Capacity you can add the week you need it.
Thin test coverage away from the core, with tests concentrated where money, authentication and the main flow live.
Plain internal screens, minimal settings, and configuration hardcoded in one file that is easy to find.
A monolith. Splitting a system nobody understands yet into services is the expensive mistake, not the safe one.

Not acceptable, at any stage

Passwords stored badly, secrets committed to the repository, permission checks that exist only in the interface.
Personal data collected without a reason, kept without a limit, or impossible to delete on request.
No migrations, and a schema that exists only in one developer's local database.
Money handled without idempotency, without an audit record, and with no way to reconcile against the provider.
No backups, or backups nobody has ever restored.
No error tracking, so failures are discovered from a customer email.
A data model that cannot represent reality and is held together with special cases.
Deploys performed by hand from a laptop, with no way back.

Everything on the first list can be repaid in a sprint. Everything on the second turns into a rewrite, a breach, or a letter from somebody you would rather not hear from.

08No rewrite

How to avoid a rewrite six months in.

Rewrites are rarely caused by the framework. They are caused by a system nobody can change safely any more, and the causes are consistent enough to list.

A data model that was wrong at the start and got worked around instead of corrected.
Business rules spread through the screens, so changing one means finding it in eleven places.
No boundary at the edges: a payment provider, an email service or an external API called directly from everywhere, so replacing one touches the whole codebase.
No tests where the money is, so nobody dares to refactor and the code calcifies.
A stack chosen because it was interesting, understood by one person, who has since left.
Six months of accumulated temporary, never written down and never scheduled.

What prevents it

Model the domain properly on day one. It is the cheapest thing in the project and the most expensive to change later.
Keep business rules in one layer, separate from the interface, whatever this year's framework fashion is.
Put an interface in front of every external service so it can be replaced without surgery.
Migrations from the first commit, with the schema's history in the repository.
Tests around authentication, payment and the core action. The rest can be tested once it stops moving.
Boring, well-documented technology that people in your market can actually be hired to maintain.
A written list of the shortcuts taken and what it would cost to undo each one, reviewed at the end of the MVP instead of rediscovered by whoever comes next.

And the question that decides more than any of the above: who owns it. The repository, the infrastructure accounts and the domains are yours from the first commit. If you carry on with us it should be because the work is good.

09Working together

Scope, budget and how the work runs.

An MVP starts with a scoping conversation, not a proposal template. Tell us the user, the job, and the assumption that worries you, and you get back a scope, a phase plan and an estimate you can argue with.

Written scope before the build. A change is a decision with its own estimate, never a quiet addition.
Two-week sprints with a demo at the end, so you steer with working software.
Nearshore from Tunis at UTC+1: a full European working day overlaps with yours. We work in English, French and Arabic.
Support continues after launch, because the weeks after release produce the feedback that was the point of the exercise.

Budget bands for an application or an MVP, and what moves them, are published on what it costs. How the work actually runs — scoping, sprints, handover — is on how we work.

Questions

The questions that come before a contract.

What counts as an MVP, and how is it different from a prototype?: A prototype is something to look at and click through: nothing behind it is real, and it is thrown away once it has answered its question. An MVP is working software with real users, real data and, if you charge, real payments — it is just deliberately narrow. A first version is what an MVP becomes once you keep building on it. The test is not how many features are in it. It is whether one kind of user can complete the one thing the product exists to do, end to end, without someone filling the gaps by hand.
How do you decide what goes in and what waits?: We start from the single path that has to work — what a user follows from signing up to getting the thing they came for — and everything on that path goes in. Everything beside it waits: extra roles, admin screens a spreadsheet can cover for now, settings nobody has asked for, the second payment method, the analytics dashboard. Two questions settle most of the argument. Does the product fail without it? And can it be done by hand for the first few weeks without embarrassing anyone? What survives both goes into the scope, in writing, before the build starts.
Does the MVP code get thrown away later, or does it become the real product?: It becomes the real product, and we build it that way: the same language and framework we would use for a full build, tests around anything touching money and data, database migrations from the first week, one command to deploy. An MVP cuts scope, not engineering. The shortcuts we do take are visible ones — a hosted service instead of something built in-house, an admin screen that is plain rather than designed, a manual step behind a button — and each is written down with what it will cost to replace. It is the invisible shortcuts, like untested payments or a database with no way to evolve it, that force a rewrite six months later.
Who owns the code?: You do. The repository is yours from the first commit and stays yours whether we continue together or not. The same goes for the hosting accounts, the domain, the database and any third-party services opened for the product: they are set up in your name, not ours. There is no proprietary framework to license and nothing that has to be transferred later.
What happens when the idea changes mid-build?: It usually does, and that is part of why you are building an MVP rather than the whole thing. Small changes go into the current sprint by taking something else out of it, not by quietly moving the date. Anything larger gets a written estimate of cost and schedule before it is built, and you decide. What we ask in return is that a change is a decision and not a hesitation: putting a feature in and pulling it out repeatedly costs more than either version of it. Every accepted change is tracked against the original written scope, so at the end you can see what you actually bought.
How long before we have something people can use?: We do not give a number before we know the scope, because the honest answer depends on things we have to see first: how many kinds of user the product has, whether it needs payments and through which provider, whether it has to connect to systems you already run, whether the design exists or still has to be made, whether the app stores are involved, and how fast decisions come back from your side — that last one moves the date more than anything technical. What we do commit to is dated milestones written down before development starts, and software you can log into at the end of every sprint, so you are never waiting until the end to find out where the project stands.
What does an MVP cost?: The cost follows the scope, so we size the work before quoting rather than after. Two models: a fixed price against a written scope when the first release is clear enough to fix, or a monthly rate when priorities will keep moving — which is common for a product that has not met its users yet. The band we work in for an app or an MVP build is published on the What it costs page instead of being kept back for a call. The scoping conversation that produces the estimate costs you nothing.
What happens after launch?: Defects against the agreed scope are ours to fix, not a new invoice. Beyond that, the useful work is reading what the first weeks of real usage told you, which is why we instrument the main path before launch rather than after — so there is something to read. From there you either keep us on for the next release and maintenance, or take the documentation, the deployment pipeline and the running product and continue with your own developers. We run our own product, Dextra, a coaching web app with real users, real coaches and real payments, so what happens after launch is not a theoretical question for us.