SaaS development services for multi-tenant products
We build subscription products end to end: the feature your customers pay for, and the tenancy, billing, onboarding, roles and operator console that let you sell it to many companies at once.
| organization | plan | seats | subscription |
|---|---|---|---|
| harbor-dental | Team | 18 / 25 | active |
| kestrel-legal | Enterprise | 140 / 150 | active |
| pine-and-co | Team | 6 / 10 | trialing |
| vela-studios | Starter | 3 / 3 | past_due |
kestrel-legal · entitlements
- seats150
- sso.samlon
- audit_log365 days
- api.rate600/min
- storage500 GB
- sandbox1
platform
What a SaaS product needs besides its main feature
The core feature is what customers buy. These ten pieces are what make it a product you can sell, bill and support, and they are the bulk of custom SaaS development. Getting them right early is what lets the core feature keep growing. If the idea is still being validated, SaaS MVP development covers the first release before the full platform.
-
tenancy
Tenancy
Every customer organization isolated from the others in data, files, jobs and caches, by design rather than by convention.
-
signup
Sign-up and onboarding
Self-serve sign-up or sales-led provisioning, invitations, sample data and the first-run steps that get a team to value.
-
identity
Authentication and SSO
Passwords and MFA for small teams; SAML or OIDC single sign-on and SCIM user provisioning for enterprise customers.
-
roles
Roles and permissions
Owner, admin, member and viewer as a baseline; custom roles when your larger customers ask for them.
-
billing
Plans, subscriptions and billing
Plans, trials, upgrades and downgrades, proration, invoices and failed-payment handling through a billing provider.
-
entitlements
Entitlements and usage
Feature flags and limits per plan, usage metering where you charge by use, and clear messages when a limit is reached.
-
console
Operator console
Your team’s back office: find any tenant, see its plan and health, impersonate with consent, extend a trial, apply a credit.
-
audit
Audit log
A per-tenant record of who did what, which enterprise buyers will ask to export.
-
api
Public API and webhooks
Documented, versioned, rate-limited API keys per tenant, so customers can integrate the product with their own systems.
-
operations
Observability and operations
Metrics, logs and alerts per tenant, backups and restore drills, zero-downtime deployments and data migrations.
architecture
Choosing a tenancy model
How tenants are separated is the hardest decision to change later. There is no universally right answer; there is a right answer for your data, your customers’ compliance demands and your operating budget.
-
Shared database
tenant_id on every row
-
Schema per tenant
one database, separate schemas
-
Database per tenant
separate databases
| Compared on | shared database | schema per tenant | database per tenant |
|---|---|---|---|
| Isolation | Logical: enforced in code and database policies | Stronger: separate schemas | Strongest: separate databases |
| Cost per tenant | Lowest | Moderate | Highest |
| Schema changes | One migration for everyone | Run per schema | Run per database, orchestrated |
| Typical fit | Many small and mid-size customers | Mid-market, some separation required | Enterprise or regulated customers, data residency |
pricing in code
Plans, entitlements and billing
Plans change far more often than code should. So the product checks entitlements (seats, SSO, audit retention, API limits) and the plan is just a bundle of them, managed in the operator console and synchronised with the billing provider.
That makes new plans, custom enterprise deals and grandfathered customers a configuration change, not a release.
| entitlement | Starter | Team | Enterprise |
|---|---|---|---|
seats | 3 | 25 | contract |
sso.saml | - | - | included |
audit_log | - | 30 days | 365 days |
api.rate | 60/min | 300/min | 600/min |
storage | 10 GB | 100 GB | 500 GB+ |
subscription states
What the product does in each subscription state
Billing events arrive from the billing provider as webhooks and move the tenant between states. The product’s behaviour in each state is a decision worth writing down.
- Trialing (completed) full access · day 1–14
- Active (current state) paid · entitlements on
- Past due (not reached) payment failed · grace 7 days
- Read-only (not reached) data kept · export allowed
- Canceled (exception path) retention then deletion
- trialing → activeCard added or contract signed; entitlements switch from the trial bundle to the plan.
- active → past_dueBilling provider reports a failed payment; owners get in-app and e-mail notices, nothing is blocked yet.
- past_due → read_onlyGrace period ends; users can still see and export data but can’t create new work.
- any → canceledData kept for the agreed retention period, then deleted with a record of deletion.
customer roles
Roles inside each customer organization
Your customers manage their own teams. A clear baseline of roles covers most of them; enterprise customers bring SSO groups and ask for custom roles.
org: kestrel-legal
- ownerSigned the contract
- adminRuns the workspace
- memberDoes the work
- viewerReads and comments
Users can come from SSO groups mapped to these roles.
your company
- operatorConsole access across tenants, audited
| role | billing | users | settings | content | export | available actions |
|---|---|---|---|---|---|---|
| owner | allowed | allowed | allowed | allowed | allowed | Change planTransfer ownership |
| admin | view | allowed | allowed | allowed | allowed | Invite userConfigure SSO |
| member | not allowed | not allowed | not allowed | allowed | own | CreateEditShare |
| viewer | not allowed | not allowed | not allowed | view | not allowed | Comment |
-
owner Signed the contract
canbilling, users, settings, content, export
seesChange plan · Transfer ownership
-
admin Runs the workspace
canbilling (view), users, settings, content, export
seesInvite user · Configure SSO
-
member Does the work
cancontent, export (own)
seesCreate · Edit · Share
-
viewer Reads and comments
cancontent (view)
seesComment
definitions
Software, SaaS and SaaS web applications
People ask whether software and SaaS are the same thing. They aren’t: SaaS describes how software is delivered and paid for.
Installed software runs on each customer’s own machines or servers, and each copy is upgraded separately.
SaaS (software as a service) is one product, hosted by the vendor, used by many customer organizations through a browser or apps, paid for by subscription and upgraded for everyone at once.
A SaaS web application is the browser-based product itself, and SaaS web application development is most of the work. In practice, building one means building a multi-tenant web application with billing and onboarding attached. That overlap is why SaaS development sits next to our custom web application development, and why platform businesses with many sellers belong with marketplace development.
how we work
SaaS product development services, stage by stage
Our SaaS application development services run from the first architecture decision to continuous releases, with the enterprise features scheduled before your first large deal rather than during it.
-
Step 1: Product and architecture definition
Who the customers are, what they pay for, which tenancy model fits your data and compliance needs, and which parts to buy rather than build (billing, identity, e-mail).
you getArchitecture decisions on paper, a plan and a scoped first release.
-
Step 2: First paying version
The core feature plus the platform plumbing it needs to be sold: sign-up, tenancy, roles, a plan and billing, an operator console.
you getA product customers can sign up for and pay for.
-
Step 3: Ready for larger customers
SSO and SCIM, audit log, custom roles, data export, uptime commitments: the things enterprise procurement asks for.
you getAnswers for security questionnaires, backed by working features.
-
Step 4: Continuous delivery
Releases behind feature flags, metrics on adoption, and a cadence agreed with your product team.
you getSmall, frequent, reversible releases.
Rebuilding an existing product on a better foundation? See web application modernization. Preparing a budget? Read what drives the cost of a custom web application.
faq
Frequently asked questions
What is SaaS application development?
It is building software that many customer organizations use over the internet on a subscription. Besides the product’s own features, it means building the platform around them: tenant isolation, sign-up and onboarding, authentication and SSO, roles, plans and billing, an operator console and the operations to run it reliably.
What does a SaaS development company do?
A SaaS app development company (or SaaS software development company) designs, builds and often operates subscription software for a product owner: architecture and tenancy decisions, the product features, billing and identity integrations, the admin back office, infrastructure and ongoing releases.
Is software the same as SaaS?
No. SaaS is a way of delivering software: the vendor hosts one product that many customers use through a browser and pays for on subscription, rather than each customer installing and running their own copy.
How do I create my own SaaS product?
Start from a specific customer problem and a pricing idea, decide the tenancy model early, buy commodity parts such as billing and identity, and build the core feature plus just enough platform to sign up and pay. Then add enterprise features when larger customers ask for them.
How much does it cost to build a SaaS application?
The main drivers are the complexity of the core product, the tenancy and compliance requirements, the billing model (flat, per seat or usage-based) and how much enterprise functionality such as SSO and audit logs is needed at launch. Our cost guide explains how to scope it.
What is multi-tenancy?
Multi-tenancy means one running application serves many customer organizations while keeping their data separate. Tenants can share a database with a tenant identifier on every row, have their own schema, or have their own database, with different trade-offs in isolation, cost and maintenance.
Do enterprise customers need single sign-on?
Usually yes. Larger customers expect SAML or OIDC single sign-on with their identity provider, and often SCIM to create and remove users automatically. Designing for it from the start avoids a painful retrofit.
Who owns the code and the product?
You do. The code, infrastructure, data and accounts with third-party providers belong to you, and the product can be maintained by your own team later.
project brief
Tell us about your product
Who your customers are, how they’ll pay, and where the product is today. We reply with questions about tenancy, billing and scope, then a proposal.
- 01
We read it and reply with the questions that decide scope.
- 02
A working session mapping records, roles, rules and integrations.
- 03
A written proposal with phases, assumptions and what each phase delivers.