Launching a SaaS: from idea to MVP to your first subscribers

You’ve spotted a problem that many businesses share, and you have an idea for software to solve it. Launching a SaaS (software as a service: software used online and paid for by subscription) is a great business venture. The trap is well known: spending months building a complete product, only to discover that nobody is willing to pay for it.

The right approach is more modest, and safer: validate the problem, build an MVP, a first version stripped down to the essentials, then learn from your first users. Here is the method we follow to build subscription software, from the idea to the first subscribers.

Launching a SaaS: validate the problem before writing code

A useful SaaS solves a problem that is frequent, costly and poorly solved. Before writing a single line of code, check that the problem really exists, in enough businesses, and that they are willing to pay to get rid of it.

The simplest way: short interviews with potential customers, focused on their day-to-day work rather than on your idea.

• How do they handle the problem today: a spreadsheet, an ill-suited tool, paper?
• How much time do they spend on it, and who deals with it?
• Have they already looked for a solution, or paid for one?
• Who would make the buying decision?

Beware of compliments: “that’s a great idea” is not validation. The real signals are actions: a prospect shows you the spreadsheet they have been patching together for years, agrees to test a mock-up, or asks when they can subscribe.

At this stage, clickable mock-ups are enough: quick to produce, they draw concrete reactions before you commit any development budget.

Defining a SaaS MVP: the smallest version that delivers value

An MVP (minimum viable product) is not a half-baked product. It is the smallest version of your software that genuinely solves the main problem for a specific type of customer: useful enough that people will pay for it, small enough to be delivered quickly.

To define it, we start from a single journey: the one that takes a new user from sign-up to their first concrete result, for example a quote sent or an appointment booked. Every feature idea then goes into one of these three categories:

1. In the MVP: without it, the main journey doesn’t work.
2. By hand, for now: your team handles it behind the scenes for the first customers, such as importing their data.
3. Later: useful, but not essential to prove the product’s value.

Two subjects, however, are never postponed: security and data protection. From day one, your customers trust you with real information.

SaaS foundations: many customers, one platform

A SaaS serves many businesses with the same software, and each one must feel at home in it: its own data, its own users, its own settings. This is called a multi-tenant architecture, where each customer is a “tenant”. There are three main options for keeping the data separate:

• A shared database, where every record carries its customer’s identifier: the simplest to run, often ideal for getting started, provided every query is rigorously filtered by customer.
• A “schema” per customer, meaning a separate space within the same database: cleaner isolation, slightly heavier to run.
• A database per customer: the strongest isolation of the three, useful for highly sensitive data or demanding large accounts, but every change must be applied to every database.

In every case, we add automated tests that check that one customer never sees another’s data. This strict separation is the golden rule of SaaS: it must be proven, not assumed.

Around this core, also plan for:

• roles within each customer account: an administrator who invites colleagues and manages the subscription, and users with suitable permissions;
• secure sign-in, with two-step verification;
• automatic backups, with a restore that has already been tested;
• automated releases: every change is tested, then deployed the same way every time, a practice our founder was already applying with Jenkins and SonarQube at Orange Business Services;
• cloud hosting in your name, on Azure or AWS, so that you keep control of the infrastructure and ownership of your data.

Subscriptions and payments: automate from the start

Subscription software comes with a whole life cycle to manage: trial, sign-up, renewal, plan change, declined payment, cancellation. None of it should depend on someone checking off payments by hand.

For this, we integrate a well-established online payment service that handles cards, recurring payments, reminders after failed payments, and invoices. The application follows a simple rule: it grants or restricts access according to the subscription status, which the payment service reports to it at every change.

On pricing, simplicity pays off at launch:

• one or two plans, easy to compare;
• a pricing unit that follows perceived value: per user, per company or based on usage;
• a free trial if people can discover the product on their own, a demo if it benefits from being presented;
• prices you can revise: your first customers will teach you what the product is worth to them.

Before the first subscriber, also set the ground rules of the subscription: terms and conditions, VAT according to the customer’s country (to be checked with your accountant), and what happens to the data after a cancellation.

From first sign-ups to first subscribers

An onboarding journey that leads to the first result

Onboarding guides each new user with a single goal: getting them to their first concrete result quickly.

• A short sign-up: the essentials first, the rest later.
• A first screen that guides users through a few steps, rather than a tour of every feature.
• Empty pages that help users get started: sample data clearly labelled as such, or an import from a spreadsheet.
• Emails triggered by usage, for example a helping hand when a user gets stuck at a step.

With your very first customers, go further: talk to them by video call and watch how they use the product.

Measuring usage

In your admin dashboard, track a few simple metrics:

• activation: the share of sign-ups who reach their first result;
• retention: do your customers come back, week after week, and keep paying?
• conversion of trials into subscriptions;
• cancellations, and above all the reasons behind them: ask, every time.

These measurements often rely on personal data: collect only what you need, in line with the European Union’s GDPR and any other data protection rules that apply to you.

Iterating at the right pace

Ship in small, regular steps, and tell your customers what is changing. A sensitive new feature can first be switched on for a few volunteer customers. Write down every request, without building everything: behind every solution customers ask for lies a problem, and that problem is what you need to understand.

Checklist before you open sign-ups

Before you welcome your first subscribers, every one of these points should be ticked:

1. The problem has been validated by potential customers, not just by the people around you.
2. The scope of the MVP is written down, along with the list of what will come later.
3. The main journey has been tested by real users.
4. Automated tests prove that one customer never sees another’s data.
5. Payment works in every case: success, decline, plan change, cancellation.
6. The terms and conditions and the privacy policy are online.
7. Backups are running, a restore has been tested, and alerts warn you of any outage.
8. Your customers know how to reach you, and usage metrics are in place.

Frequently asked questions

Do you need a mobile app to launch a SaaS?

Rarely at the start. A web app that adapts to phone screens is enough for many SaaS products aimed at businesses, with only one version to maintain. Mobile makes sense if your users work on the move or need the phone’s features: see our criteria for choosing between a web app and a mobile app.

How much does it cost to build a SaaS MVP?

It depends mainly on the complexity of the main journey, the integrations and the level of security required. That is the whole point of an MVP: a tight scope, and therefore a budget that is easier to control. The factors that drive the cost of custom software also apply to a SaaS. One possible combination: a fixed price to build the MVP, then a monthly subscription to keep it evolving.

In short

Launching a SaaS means moving forward one proof at a time: a validated problem, an MVP that solves the essentials, solid foundations for many customers, automated subscriptions, then metrics that guide each new version. Starting small is not a lack of ambition: it is the surest path to a product your customers choose to keep, month after month.

Have a product idea? Book a free 30-minute discovery call: together, we’ll look at the problem to solve, your target customers and the scope of a realistic MVP.