The SaaS development company that runs its own SaaS

A SaaS isn't a website with a login. It bills every month, keeps each customer's data apart and can't go down overnight. Still on version one? Start with MVP development. Building a tool for your own team? See custom web apps.

Anatomy

What is a SaaS product made of?

Seven stacked layers, and the interface your customers see is only the top one. The other six decide whether the product gets paid, keeps data safe and holds up as the customer list grows.

Interface
The web app your customers use: onboarding, the screens where work happens, settings. Built in Next.js and React, quick on a phone and ready to become an app.
API
Connects the interface to the data and to other services: mobile apps, integrations, automations. Versioned, documented, with usage limits per customer.
Authentication and roles
Who gets in and what they can do: sign-in, invites, roles for teams and admins. Every request checks permissions on the server, not just in the interface.
Subscriptions and payments
Plans, free trials, renewals, cancellations, invoices. A payment provider on the web; in-app purchases inside the mobile apps where the store rules call for them.
Multi-tenant data
One shared database where every customer's data stays separate. The schema is built around the customer from day one, because retrofitting it means rewriting half the product.
Infrastructure
Servers, databases, job queues, staging and production. We decide where the data lives and automate releases, so every change goes through the same checks.
Monitoring and backups
Errors, metrics and alerts, so you hear about a problem before your customers do. Automated database backups, with a copy kept off-site.

The phases

How is a SaaS product built, from idea to scale?

In six phases, and the first two happen before anyone writes code. They are the ones that cost the most when skipped.

Scope
Who pays, for which problem, and what solving it is worth. We pin down a first scope you can measure and the metrics that will tell you it works.
Architecture
Tenancy model, roles, plans and pricing, where the data lives. These are the hardest choices to reverse later, so we write them down.
Product design
Flows, a clickable prototype and a design system, tested with real users before they're built. That's our product design and UX work.
MVP
Sign-in, subscriptions, the one feature that justifies the price, and a dashboard. With CI, separate environments and backups running from the first release.
Launch
Onboarding, system emails, tracking for activation, recurring revenue and churn. The first customers come in and we measure what they actually do.
Growth
Data-led iterations, integrations, mobile apps, performance under load. When the product takes off, that's the scale-up stage.

Architecture

Which architecture decisions should you make up front?

Five of them, ideally on paper before any code: each is easy to settle on day one and expensive to change once customers are in.

Typical SaaS architecture decisions and when each route makes sense
Decision	Route A	Route B	How we decide
Tenancy	Single-tenant: one instance and one database per customer	Multi-tenant: one shared instance, data kept apart per customer	Multi-tenant for nearly every startup: lower running costs, simpler upgrades. Single-tenant when a large customer needs full isolation in the contract.
Data isolation	Shared tables, with the customer on every row	A schema or a database per customer	Shared tables with automated checks to start with; separate schemas when customers are few, large and come with their own requirements.
Pricing model	Subscription, per plan or per seat	Usage-based: pay for what you use	Subscriptions when value is steady: predictable revenue. Usage-based when value grows with use (APIs, AI, messages), with precise metering.
Payments in the apps	Pay on the web through a provider	In-app purchases on the App Store and Google Play	Depends on what you sell: on iOS, unlocking digital features inside the app generally has to go through Apple's in-app purchases. Settle it before review.
Hosting	Managed cloud platforms, billed by usage	Dedicated or virtual servers run by the team	Managed platforms to get moving fast; your own servers when control, predictable costs and data in Europe matter.

First-hand

How do we run our own SaaS, Athleex?

A glass slab with raised bars and a rising curve, like a revenue and churn dashboard

Athleex is the group's SaaS for personal trainers and coaches, with an app for their athletes. We designed it, built it and keep growing it ourselves, so every choice on this page was made on our own product first.

Inside there's a business dashboard showing recurring revenue, churn and customer lifetime value, plus a Churn Radar that flags athletes likely to drop out before they do: the numbers a SaaS operator needs, inside the SaaS itself.

Application: Next.js, multilingual interface
Data: PostgreSQL, via Prisma
Servers: European (Hetzner), run by us
Releases: Automated CI on GitHub Actions
Backups: Nightly, with an off-site copy
Apps: iOS and Android with Capacitor, same codebase

Read the Athleex case study

Questions about SaaS development

How much does it cost to build a SaaS platform?

It depends on how many layers the first release needs, how many integrations, and whether it's web only or apps too. We don't publish a price list: after a first call we give you an estimate against a written scope. What drives the number is explained in pricing and timelines.

How long does it take to build a SaaS product?

The scope matters more than the technology. A first release with sign-in, subscriptions and the core feature is far quicker than a full platform, which is why we agree the scope first and the timeline second, in writing.

What is a multi-tenant architecture?

One application serving many customers (tenants) while keeping their data apart. It's the most common SaaS model because it cuts costs and makes upgrades simpler; the data separation has to be designed into the schema from the start.

Subscription or usage-based pricing?

Subscriptions give predictable revenue and are easier to explain. Usage-based pricing works when value grows with use, as with APIs or AI features, but you need to meter usage precisely. Plenty of SaaS products combine a base plan with a usage component.

Can you start from a prototype I already have?

Yes. If you built it with no-code tools or AI, we assess it and decide with you what to keep and what to rewrite. That's what our prototype to production service is for.

Can the SaaS have a mobile app too?

Yes. With Capacitor the same web codebase becomes an iOS and Android app, as it did for Athleex; when the product calls for it we look at React Native, Flutter or native. More on our app development page.

Got a SaaS to build or to grow?

We reply within one business day.

Let's talk

What is a SaaS product made of?

Interface

API

Authentication and roles

Subscriptions and payments

Multi-tenant data

Infrastructure

Monitoring and backups