MVP: starting small without rebuilding later

“Let’s start small” is a good instinct, on one condition: the small thing has to be able to grow. Many companies pay for the same application twice, because the first version was built like a throwaway mockup. Here is how I scope a business software MVP: what to cut, what to keep, and what it costs.

What an MVP really means for a business

At a startup, an MVP tests whether a market exists. At an established company, the question is different. The need is already known (a team re-enters data, a spreadsheet is overflowing, a legacy tool can no longer keep up), and the goal is to get the most valuable part into production quickly, without blocking what comes next.

A good business software MVP checks three boxes:

• it replaces a real process end to end, even a narrow one (order taking, for example, not “a bit of everything”);
• it is used every day by a real group, not just shown in meetings;
• it sits on foundations that can take the next batches without a rewrite.

Prototype, MVP, full version: orders of magnitude

These amounts exclude VAT and come from my public pricing. The quote becomes fixed after scoping.

An illustrative example, using the estimator’s building blocks: an MVP for tracking field jobs with accounts and roles (€1,500), an admin back office (€2,000) and a dashboard (€1,500) on top of the application’s core; the connection to your accounting software (€2,000) can wait for batch 2. For your own case, the estimator gives you a range in one minute.

What you can safely cut

To keep an MVP on budget, I cut the scope, never the construction. These can wait:

• secondary user profiles: if sales reps are the core of the need, the management view can come in batch 2;
• convenience automations: automatic reminders, custom exports, fine-grained notifications;
• non-critical integrations: a clean CSV export can stand in for a live sync for a few weeks;
• premium design: a clean, fast, consistent interface is enough to get started;
• edge cases: the process that affects 2% of records can stay manual at first.

What you should never sacrifice

These are what separate an MVP that grows from one that gets thrown away.

1. The data model. Customers, orders, products, jobs: the database structure has to reflect how your business really works, including what will come later. Changing a data model in production costs far more than thinking it through during scoping.
2. Accounts and permissions. Even with two profiles at the start, the role system has to be designed to take more.
3. Baseline security: solid authentication, restricted access, backups, and data hosted in a GDPR-compliant setup.
4. Readable, version-controlled code that you own. With me, the source code and rights are transferred to the client once the project is paid in full. That is what lets you keep working with me or with another provider.
5. A standard stack. I use widely adopted technologies (React, TypeScript, Node.js, PostgreSQL through Supabase) so that any competent developer can pick up the project.

These are exactly the things that prototypes generated too quickly tend to lack. If that is where you are, the page on taking an internal prototype to production explains how to sort what to keep.

When an MVP is not the right approach

To be straightforward: a custom MVP does not make sense in every case.

• An off-the-shelf product already covers 80% of the need and the rest can adapt: use it, and keep custom software for later if it is ever needed.
• The need is not yet clear inside the company: a few scoping workshops and mockups are worth more than premature development.
• The process cannot be split: a regulatory deadline or a full switch away from legacy software sometimes requires a larger minimum scope.
• Nobody has time to test: an MVP with no available pilot group teaches you nothing.

How an MVP project works

1. A 30-minute call to pinpoint the process that brings the most value.
2. Scoping (1 to 2 weeks): MVP scope, a list of what is deferred, fixed quote and schedule. The requirements document clearly separates batch 1 from the rest.
3. Clickable mockups (1 to 3 weeks) tested by the future pilot group.
4. Development in batches, each tested by your team.
5. Go-live for the pilot group, migration of the useful data, training, then 3 months of included support.
6. A usage review before pricing the next batch, based on what the team actually uses.

Payment follows the same rhythm: a 50% deposit at the start and a fixed price per batch. The details of the offer are on the business apps page.