Subscription SaaS platform: how we build it from the first module

A SaaS (“software as a service”) product is an application that your customers use from the browser and pay for monthly or annually, without installing anything. Anyone searching for “SaaS platform development” usually has a half-tested idea: they know a problem in a particular field well and want to sell the solution to many companies at once.

The biggest risk is not technical. It is spending a long time building a product nobody pays for. That is why we propose a small first version, usually called an MVP (minimum viable product, that is, the smallest product that can be sold), with the foundations done properly and the rest openly postponed.

SaaS platform development: what goes into the first version

The first version does one thing well: the thing someone would get their card out for. Say you want a product for running gyms. The feature that sells might be tracking memberships and check-ins; elaborate reports, the mobile app and the link to the turnstiles can wait.

Around that feature, however, there is a part you cannot skip, because without it you have a prototype, not a product.

• Sign-up and login: new account, email confirmation, password reset.
• The customer’s space: each subscribing company has its own data, users and settings.
• Roles: at least owner, administrator and standard user, with invitations by email.
• Subscription: choosing a plan, paying, changing plan, cancelling.
• Onboarding: a few steps that take the person to their first useful result, with sample data.
• Admin panel: for you, so you can see the accounts, the payments and the problems.

Separate accounts for each customer: how we keep the data apart

The architecture in which one application serves several customers is called multi-tenant (each customer is a “tenant”). In the most common setup, all of them share the same database, and every row carries the identifier of the company it belongs to. In the other, each customer has a database of its own.

The first is simpler to maintain and suits most products that are just starting out. The second isolates better and helps when you sell to large companies, but complicates updates. Whichever you choose, the separation is enforced in a single place in the code, not on every screen, and is checked by automated tests that deliberately try to read another customer’s data.

Subscriptions and billing through a payment processor

We do not write recurring payment logic from scratch. We use a processor (Stripe is a common example) that stores the cards, handles renewals, retries failed payments and notifies the application through webhooks, that is, automatic messages sent at each event: payment succeeded, payment failed, subscription cancelled.

The application listens for these messages and opens or restricts access. You decide the commercial side: trial period or not, plans by number of users or by volume, what happens to the data of someone who stops paying. The tax treatment of sales, especially to other countries, is clarified with your accountant before the processor is chosen.

What we deliberately leave for later

Every postponed feature is time gained for finding out what the first users really want. We keep a written list of what does not go into the first version, so that it does not creep back in along the way.

What we never postpone: backups, data separation and the ability for a subscriber to export their data. These are very expensive to fix once you have users.

• The native mobile app: a web interface that looks good on a phone is enough to begin with.
• The programming interface (API) for third parties: added when someone who pays asks for it.
• Complex reports: a spreadsheet export covers the early needs.

The pace of work and the tools behind it

For products like this we prefer Laravel, a PHP framework that provides, in its core or through official packages, authentication, job queues and the link to some payment processors. The data lives in PostgreSQL or MySQL. Slow tasks (emails, imports, reports) run in the background, and every change goes through a suite of automated tests before release.

What we cannot do: validate the market for you. We can build the tools you measure with (how many sign up, how many reach the first result, how many pay after the trial period), but the conversations with the first customers are yours.

• The kick-off workshop: we map the user’s route from sign-up to first result and cut the rest.
• The skeleton: accounts, each customer’s space, roles, a test environment.
• The core feature: built in short cycles, with a demo at the end of each.
• Payments and onboarding: added once the core feature can be shown to someone outside.
• The first users: a small group, whose stumbling blocks produce the next list.

This is a typical project description: it shows how we usually approach this kind of work and does not present a project carried out for a particular client. Every real project starts from your company’s situation, and the stages, timescales and price are agreed after the initial discussion.