Socle massif en pierre noire portant un noyau de cristal violet et plusieurs univers autonomes en orbite.

Product & software

SaaS development and product creation

Building a SaaS is not an app with a pricing page. It is a product that must isolate its customers, collect payment every month, be administered, and stay up while you sleep. Those four points decide, not the homepage.

Start a project See the work

Expertise: Product & software
Nature: Multi-tenant product sold on subscription
Scope: Product · architecture · billing · operations
Stack: TypeScript · PostgreSQL · documented API
Proof: Stellary, our own SaaS in production

01 / 08

What a SaaS demands beyond an application

Every query goes through the tenant filter. Forget it, and one customer sees another's data.

SaaS development differs on one point: an application serves one client, a SaaS serves hundreds, on the same codebase, without anyone seeing another's data. That constraint runs through the whole product: the data model, queries, backups, logs, exports. It is decided on day one and is very hard to retrofit.

Then comes the money. Trials, prorated plan changes, failed charges, dunning, refunds, VAT by customer country: subscription billing is a domain of its own, not a payment button.

Then operations. A SaaS updates for everyone at once, without downtime, with database migrations that must run on real data. That is what distinguishes a product from business software deployed for a single client.

02 / 08

What to build, and in this order

Order matters: each of these bricks costs far more to add later than to set at the start.

01
Isolation
An organisation, its members, its data. Isolation lives in the model and is verified by tests: a query that forgets the tenant filter is the most ordinary and the most serious SaaS flaw.
02
Subscriptions
Plans, trials, proration, mid-cycle changes, failed payments, dunning, refunds. The payment provider collects; it is your product that must know what each customer is allowed to do at every moment.
03
Roles
Owner, admin, member, guest. Explicit permissions rather than a pile of conditions in the screens — that is what lets you add a role later without rereading everything.
04
Arrival
Sign-up, space creation, inviting the team, a first useful result. SaaS drop-off is decided in the first minutes, long before the trial ends.
05
Administration
See accounts, help a customer, extend a trial, refund, read the logs. Without this tool, every support request becomes a SQL query written by hand in production.
06
Observability
Errors surfaced, usage metrics, alerts on what deserves a wake-up. A product customers pay for cannot wait for a user to report the outage.

03 / 08

From the first user to a product that holds

The feature set can stay minimal; the foundations cannot. That is what decides whether the product extends or is rewritten.

01
Scope what you sell
Which problem justifies a recurring subscription, for whom, and at what price. A SaaS without a clear answer to those questions becomes custom software in disguise, with product costs and service revenue.
02
Build the core, not the catalogue
A first version that does one thing fully, with isolation and billing in place. A half multi-tenant product is rewritten; a product with one feature extends.
03
Confront real customers
The first users reveal what no specification had planned — often a starting assumption about their internal organisation. Better to discover it on a handful of accounts than at scale.
04
Industrialise
Zero-downtime deploys, replayable migrations, backups restored for real, monitoring and on-call. This is when the product stops depending on the person who wrote it.

04 / 08

What you receive

The subscription chain as shipped: each state, and the dunning that brings a failed payment back to active.

A multi-tenant product whose isolation is tested, not only claimed.
The full subscription chain: plans, trials, proration, failed payments, invoices.
An admin that lets you help a customer without touching the database.
Automated deployment, replayable migrations, and verified backups.
The code, the database, and the documentation: the product is yours, including if you change vendor.

05 / 08

We operate our own SaaS

Stellary · See the case study

The studio does not only sell SaaS development: it runs some. Stellary is a multi-tenant platform with organisations, workspaces, permissions, billing, administration, and monitoring — built, deployed, and maintained here.

That changes two things on a brief. First the trade-offs: we have already paid for the bad ones, on our own products. Then honesty on timelines — when you operate what you sell, you know what the second year actually costs.

The same foundation serves clients: Créarègle carries recurring payment, distinct roles, and infrastructure that is backed up and monitored.

Proof in context

See the work behind this expertise

Product, architecture, and operations choices, explained on real studio projects.

Case studyStellaryThe command post for teams that ship with AI agents. You describe a project, the agents move it forward under explicit rules, and a human keeps hold of what matters. Open beta.Product, design and development

07 / 08

What we get asked most

The answers we give anyway at the first conversation.

What does it cost to build a SaaS?

A first sellable version — isolation, subscriptions, and one finished feature — generally sits beyond a classic business app, because billing and isolation are incompressible work. The budget is scoped after a first conversation about what you sell and to whom.

Should you start with an MVP?

Yes, provided "minimum" applies to the feature set and never to the foundations. A product with one feature and correct isolation extends; a rich product that is poorly isolated is rewritten.

One database per customer, or a shared one?

A shared database with strict isolation covers most cases and costs far less to operate. A database per customer is justified by regulatory demands or very large customers — it is an architecture decision, not a preference.

Who handles payments and VAT?

The payment provider collects and handles VAT by customer country. Your product must know, at every moment, the subscription state and the rights that follow — that is the part we build.

What if we bring the team in-house later?

That is planned from the start: versioned and delivered code, a standard database, a documented API, automated deployment, and written procedures. A product you cannot hand over is a product that holds you hostage.