MVP development, built to survive success.

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.

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.

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.

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.

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.tn, 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 submitted to the App Store and Google Play, and not yet publicly listed — the web application is what people use today.

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.

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.

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.

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.

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.