SaaS MVP: no-code or custom development?

You have a platform idea: a booking app, a business tool, a marketplace. The first version does not need to be perfect. It needs to exist soon enough for real users to tell you whether the idea holds. That is the role of the MVP, the minimum viable product. The question is how to build it.

First, what an MVP has to prove

An MVP is not a cut-price version of the final product. It is the simplest tool that lets you test a hypothesis: “customers are willing to pay to solve this problem this way”. Anything that does not serve that test can wait.

Key point. Before choosing a technology, write in one sentence what the MVP must prove, and the list of three features without which it cannot prove it.

The two routes to build an MVP

No-code, with a tool like Bubble, means assembling the application in a visual interface: database, screens, business rules, without writing the code yourself.

Custom development means writing the application with a language and a framework, on infrastructure you control.

When no-code is the right choice for an MVP

• The idea is not validated yet and you need to learn fast.
• The product relies on screens, forms, user accounts and standard payments.
• You want to be able to change the product every week based on feedback.

Bubble bills according to the application’s actual usage. That is comfortable at the start, but consumption needs watching as the number of users grows.

When you need custom code from the start

• The core of the product is heavy computation, real time or large-scale data processing.
• Your customers impose strong constraints on hosting or data compliance.
• The product must work offline or integrate deeply with another system.

The middle route, often the best

Nothing forces you to choose forever. Many products start in no-code, prove their market, then rebuild in code the parts that need it, with revenue to fund that work. Rebuilding a product that works is a good problem. Having spent your whole budget on a product nobody uses is a bad one.

Questions to settle before you start

1. Who is the user, and what precise problem are we solving?
2. What are the three essential features?
3. How does the money come in: subscription, commission, pay per use, Mobile Money?
4. How will we know the MVP has succeeded, and by when?

At Aureva Digital we build platforms and SaaS products in Bubble or in code depending on what the project requires, and we tell you frankly when a route is the wrong one. Tell us about your idea and we will start with those four questions.

State the hypothesis before drawing a screen

An MVP answers a question. If the question is vague, the MVP will be too. A good hypothesis fits in one sentence and can be contradicted by facts.

As long as you cannot write that sentence, it is too early to build. Ten interviews with future users cost less than a badly targeted MVP.

Prototype, MVP, version 1: do not confuse them

These three words describe three different things.

• The prototype is a clickable mockup. It tests understanding, not real use.
• The MVP really works, with real users and real data, on a reduced scope.
• Version 1 is the product you build once the hypothesis is confirmed.

A prototype takes a few days and prevents many mistakes. Going straight to the MVP without a prototype means discovering in production the misunderstandings a mockup would have revealed.

Choosing the features of the MVP

The temptation is to add “just one more feature”. A simple method helps decide: put each idea into one of these four columns.

Only the first column goes into the MVP. Anything that can be done by hand at the start should be: approving an account by email, sending an invoice yourself, answering support directly. Those manual tasks teach you what to automate next.

What no-code can do today

A tool like Bubble covers the essentials of a platform MVP.

• A database with types and relationships.
• User accounts, roles and privacy rules.
• Screens that adapt to mobile.
• Workflows triggered by an action or a date.
• Connections to other services through APIs.
• Payments through a provider.

Its limits are known: cost that follows usage, dependence on the vendor, and performance to watch as data grows.

What custom code adds

Custom code is not “better”, it answers other constraints.

• Control over hosting, when a customer requires data to stay in a given country.
• Performance, for real time or large volumes.
• Deep integration with an existing system.
• Full ownership of the code, which counts in fundraising or a sale.

In return, every change to the MVP goes through a developer. So you need an available team, or a clear maintenance budget.

Payments, to think about from the MVP

Knowing whether users pay is often the hypothesis itself. So build in payment early, even in a simple form.

An MVP that takes ten real payments teaches you more than a thousand free sign-ups.

Measuring: the few figures that count

An MVP is steered with a handful of indicators, chosen before launch.

1. Activation: how many sign-ups perform the key action once.
2. Retention: how many come back the following week or month.
3. Conversion: how many agree to pay.
4. Reason for leaving: what those who leave say.

Set in advance the threshold that will confirm the hypothesis. With no written threshold, any result can be read as a success.

Security and data: the minimum, even for an MVP

An MVP handles real data from real people. The reduced scope does not excuse the basics.

• Access rules: each user only sees their own data.
• Passwords handled by the tool or a recognised library, never a home-made system.
• A regular backup of the database.
• A privacy policy that says what is collected and why.

What changes the timeline and budget of an MVP

• The number of user types: a single role or three roles with different rights.
• Integrations: each external service adds work and testing.
• Payments, especially if several methods are needed.
• The level of design polish.
• How clear the specification is at the start.

A single-role MVP with no complex integration is built much faster than a three-profile marketplace. That is why scoping comes before any costing.

Running interviews before you build

Interviews with future users are the cheapest and most instructive stage of a project. A few rules make them useful.

• Talk to people who live with the problem, not to your friends and family.
• Ask what they do today, not what they would do tomorrow.
• Look for the last time the problem came up, and what it cost them.
• Only present your idea at the end, so as not to steer the answers.
• Write down the exact words used: they will serve for your copy.

If nobody spontaneously describes the problem as painful, the product will struggle to sell, whatever the technology.

Writing the specification

A good specification fits in a few pages. It does not need to describe every button, it has to make the scope indisputable.

1. The hypothesis to test and the success threshold.
2. The types of user and what each can do.
3. The main journey, screen by screen, in simple sentences.
4. The data stored.
5. The external services to connect: payment, email, SMS.
6. What is deliberately left out of this first version.

The sixth point is the most important. Writing down what you will not do prevents most schedule and budget drift.

The typical flow of a project

Launching to a small group first lets you fix the most annoying flaws before they reach everyone.

Three examples of scope

A booking platform

The hypothesis: professionals agree to pay to receive their bookings online. The essential scope: a professional account, an availability calendar, a public booking page, an email confirmation. Everything else, SMS reminders, statistics, deposits, comes later.

A marketplace

The hypothesis: sellers and buyers meet in this niche. The trap is building both sides at once. The first version can handle only listings and introductions, with the transaction happening elsewhere. That shows whether supply and demand exist before investing in payment.

An internal tool

The hypothesis: the team saves time with this tool. Here the test is simple: after a month, is the team still using it, or back on the spreadsheet? An internal tool built in no-code changes quickly, at the pace of feedback.

After the MVP: continue, pivot or stop

Three outcomes are possible, and all three are successes if you have learned something.

• Continue: the hypothesis holds, you strengthen the product and prepare version 1.
• Pivot: the need exists, but not in the form imagined. You keep what works.
• Stop: nobody comes back or pays. Better to know after a few weeks than after a year.

The mistakes we see most often

• Building for six months without showing the product. Every week with no user feedback is a week of guesses.
• Adding features to feel safe. They delay launch and blur the results.
• Neglecting the user’s arrival. A confusing first screen makes people leave before trying.
• Measuring nothing. Without figures, decisions rest on intuition.
• Confusing interest with payment. “That’s a good idea” is not worth a first payment.

How many features at launch?

Fewer than you think. If you are not a little embarrassed by what is missing from your MVP, you have probably waited too long. The right measure: a new user must be able to complete the product’s main action, from start to finish, without help. Nothing more to begin with.

Questions people ask about the MVP

Does an MVP have to look good?

It has to be clear and inspire trust. A sober, consistent design is enough, polish will come with version 1.

Can you raise funds with a no-code MVP?

Yes. Investors look first at usage and revenue, technology comes after.

How many users do you need to validate an MVP?

It depends on the hypothesis. A few dozen active, well-observed users are often enough to decide.

Should you protect your idea before launching an MVP?

An idea is worth mostly its execution. Talk about it to your future users: their feedback is worth more than secrecy.

A short glossary

• No-code: building an application with a visual interface rather than writing code.
• SaaS: software used online, usually by subscription.
• Workflow: a series of actions triggered by an event.
• API: the way two pieces of software exchange data.
• Retention: the share of users who come back after their first visit.

Eight checks before launch

1. The hypothesis is written down, with a success threshold.
2. Ten people who live with the problem have been interviewed.
3. The scope fits on one page, exclusions included.
4. A new user can complete the main action without help.
5. Each user’s data is protected from the others.
6. Payment works, or a manual method is planned.
7. The indicators to follow are defined and measured.
8. A first group of users is ready to test.

How Aureva Digital builds an MVP

We start with the hypothesis and the scope, not the technology. The choice between Bubble and custom development comes next, depending on what the product really requires: complexity of the rules, constraints on data, expected volume. We tell you frankly when no-code is enough, and when it would limit you too soon.

The project follows our six-step method, with a prototype approved before the build and a launch to a small group first. At delivery you receive the access details, documentation of the data and rules, and a short training session. We remain available to evolve the product, in English or French, whether your users are in Cotonou, Abidjan or Paris.

What this means for a founder in Africa or Europe

The method is the same, the constraints differ. In West Africa, payment is the first question: a product that cannot take Mobile Money will struggle to charge consumers, so the payment aggregator should be chosen at the scoping stage. Many users also arrive on an entry-level phone with limited data, which argues for light screens and short journeys.

In Europe, card payment is simple to set up, but data protection rules and customer expectations on reliability are higher. Plan a clear privacy policy and access rules from the first version.

In both regions, the fastest way to learn is the same: put something real in front of a small number of users, watch what they do rather than what they say, and decide from the figures you agreed on before launch.

In short

• An MVP exists to test a hypothesis, not to deliver the final product.
• No-code lets you learn fast and at lower cost; custom code is needed when the core of the product is technical or heavily constrained.
• You can start in no-code and rebuild what needs it once the market is proven.
• First settle the user, the three essential features and how the money comes in.

Sources

• The Lean Startup: principles, including the minimum viable product
• Bubble: official pricing
• Bubble: official documentation
• GSMA: State of the Industry Report on Mobile Money 2026