SaaS Products Built With the Plumbing Included
Multi-tenancy, subscriptions, team accounts, onboarding, usage metering and an admin back office — the unglamorous two-thirds of a SaaS build that nobody demos and every product needs.
- Multi-tenant from day one
- Fixed-price first version
- Stripe-backed billing, no card data stored
A SaaS Product Is Not a Web App With a Login Page
In a normal web application there is one company using it and you are that company. In a SaaS product there are many, they sign up without talking to you, they pay monthly, they invite colleagues, they change plans, their cards fail, and they must never see each other. Each of those sentences is a system.
The feature you are excited about — the thing the product is actually for — is usually a third of the build. The rest is the machinery that lets strangers buy it and use it without your involvement. Founders who budget only for the exciting third run out of money at the point where the product starts to matter.
Compare with a single-company web appMulti-Tenancy and Where Customer Data Is Kept Apart
Every SaaS product has to answer this before the first table is created, because it is the decision that is hardest to change afterwards.
Shared schema, tenant column
One database, one set of tables, every row tagged with the tenant it belongs to. The default for the large majority of products.
- Cheapest to run — one database no matter how many customers you win
- One migration deploys a schema change to everybody at once
- Your own reporting across all customers is a single query
- Risk: one careless query leaks data between customers
- Mitigation: the tenant filter is enforced in one shared layer, never by each developer remembering
- Restoring one customer to yesterday is awkward — you are restoring a shared database
Separate database per tenant
Each customer gets their own database, provisioned when they sign up. Stronger isolation, more moving parts.
- A leak between customers becomes very difficult rather than merely guarded against
- One customer can be backed up, restored or exported on its own
- Answers the enterprise procurement question about data separation directly
- Cost: every schema change has to run across every database, and one failure leaves you half-migrated
- Cost: provisioning, monitoring and hosting all multiply by customer count
- Cross-customer reporting stops being a single query
The trade-off in one line: shared schema is cheaper and simpler but puts the isolation burden on your code; separate databases move that burden into infrastructure and charge you for it every month. We recommend shared schema unless you are selling into healthcare, finance or enterprise procurement, where the isolation question gets asked in writing. Either way we decide it with you before the schema exists, not after.
The Order We Build a SaaS Product In
Each phase ends with something you can log into. Nothing waits for everything.
Phase 1 — Foundations
Tenants, accounts, roles, invitations and the permission layer. Unglamorous, and everything else sits on top of it.
Phase 2 — The Core Feature
The thing customers are actually buying, built narrow and deep enough to be genuinely useful rather than broad and shallow.
Phase 3 — Money
Plans, trials, checkout, upgrades and downgrades, failed payments and what happens to an account that stops paying.
Phase 4 — Self-Service & Scale
Onboarding that works without you on a call, usage limits, the admin back office, and the performance pass before real volume arrives.
Subscriptions Are a Lifecycle, Not a Checkout Button
Taking the first payment is the easy part. The states a subscription passes through afterwards are where the product decisions hide.
Trial
Card up front or not? A free trial with no card gets more signups and worse conversion; requiring a card does the reverse. What happens on day fifteen if they have not converted — does the data stay, go read-only, or disappear?
Active
Monthly or annual, per seat or flat, with tax handled by the payment provider where it can be. Invoices and receipts need to be downloadable without anyone emailing your support address.
Plan change
Upgrades take effect immediately with proration; downgrades usually at the end of the period. If the lower plan allows fewer seats or less storage than they are using, the product has to say so clearly rather than silently deleting something.
Payment failed
Cards expire constantly, and this is the most common reason healthy customers churn. Retries on a sensible schedule, a clear in-app banner, emails that are useful rather than threatening, and a grace period before anything is switched off.
Cancelled
Access until the end of the paid period, an export of their data, and a defined retention window before deletion. Getting this right is also what makes winning them back possible.
Card details go to Stripe or a comparable provider and never touch your servers. We build the states above around it, and the webhooks that keep your database and the payment provider in agreement when a payment succeeds at three in the morning.
Four Things Nobody Puts in the Budget
These come up in every SaaS project we have worked on, and they are almost never in the brief we were sent.
Roles and team accounts
- A customer is an organisation, not a person — several people share one subscription
- Owner, admin and member as a minimum, with billing access separated from data access
- Invitations by email, including to people who do not have an account yet
- Removing someone without deleting the records they created
- One person legitimately belonging to two customer organisations at once
- Custom roles are a later feature — a fixed set covers the first year
Onboarding as a real feature
- The first ten minutes decide whether a signup becomes a customer
- An empty product is a dead end — sample data or a guided first task beats a blank screen
- Import from the spreadsheet or tool they are moving off
- A short checklist showing progress towards the thing they signed up to do
- Emails that arrive because of what they did, not because a week passed
- Every step measured, so you can see where people stop
Usage metering
- Counting seats, records, projects, API calls or storage per tenant, accurately
- Showing a customer where they stand against the plan limit before they hit it
- Deciding what happens at the limit: block, warn, or allow and charge
- Usage-based billing means the numbers must survive an invoice dispute
- The same counters tell you which customers are getting value and which are drifting
- Retrofitting accurate counting later means you have no history to show
The admin back office
- Your own team needs to find a customer and see their plan and usage
- Extend a trial, apply a credit, change a plan by hand when support requires it
- Sign in as a customer to reproduce a problem, with that access logged
- Suspend an account, and reinstate it without losing anything
- Basic revenue and signup numbers without exporting the database
- Without this, every support request becomes a developer writing SQL against production
What Goes in Version One, and What Waits
This is roughly how we split a first SaaS release. The line moves with your market, but the shape holds.
Non-negotiable
Tenant isolation, signup and login, one set of roles, the core feature, paid subscriptions with trials, transactional email, and enough of an admin view to support a customer.
Worth the argument
Team invitations, a real onboarding flow, usage counters, in-app notifications, and data export. Each of these can wait a release, but not three.
Wait for a customer to ask
Single sign-on, a public API, webhooks, custom roles, annual invoicing with purchase orders, white labelling, a second language, and mobile apps.
Where budgets die
A configurable rules engine, a plugin marketplace, per-customer branding of every screen, and an admin panel with more features than the product itself.
When SaaS Is the Wrong Model for You
SaaS Development Questions
What does multi-tenant actually mean?
It means one running copy of your software serves every customer, with the data of each customer kept apart from the rest. It matters because the alternative — a separate installation per customer — multiplies your hosting bill, your deployment work and your support load by every customer you win. Almost every SaaS product should be multi-tenant from the first line of code, because converting later is close to a rewrite.
Should each customer get their own database?
Usually not. A shared database with a tenant column on every table is cheaper to run, simpler to deploy, and fast to query across customers for your own reporting. The cost is that one careless query can leak data between customers, so the isolation has to be enforced in a single place and tested rather than left to each developer to remember. Separate databases per customer buy harder isolation and easier per-customer restores, which is worth the extra running cost if you sell into regulated industries or to enterprises that ask about it during procurement. We make that call with you before the schema is written, because it is not a cheap thing to reverse.
How long does a first SaaS version take to build?
Typically 12 to 20 weeks for a product with signup, billing, a working core feature and an admin back office. The range is wider than for a plain web app because SaaS carries plumbing a single-customer application never needs: tenants, roles, invitations, subscription states and the internal tools your own team requires on day one.
Do you build the billing system yourselves?
No, and nobody should. Card details go to Stripe or a comparable provider so that you never store them. We build everything around it: plans, trials, upgrades and downgrades with the right proration, retries on failed payments, dunning emails, and what the product actually does when someone stops paying. That last one is a product decision rather than a technical one, and it is the question most teams have not yet answered.
What should we leave out of version one?
Most of it. Single sign-on, a public API, granular custom roles, white labelling, annual invoicing with purchase orders and a second language are all genuine requests that arrive later from real customers. Building them before anyone has asked is the most common way a SaaS budget disappears before launch.
Can we add multi-tenancy later and start simple?
You can, and it is the decision people regret most. Adding a tenant boundary to a live product means touching every table, every query and every screen while customers are already using it. If the plan is to sell to more than one company, build the boundary in on day one. It is a small cost at the start and a large one afterwards.
What does a SaaS product cost to run once it is live?
At launch, usually tens to a couple of hundred dollars a month for hosting, plus whatever percentage the payment provider takes and the cost of your email, error tracking and support tools. It grows with usage rather than jumping in steps. We size the infrastructure for the customers you have rather than the ones you hope for, and we write down what every line of the bill pays for.
The Pieces Around a SaaS Build
Backend & API Development
The schema, the tenant boundary, background jobs and the public API customers will eventually ask for.
Learn moreWeb Application Development
The product surface itself — screens, roles, performance at volume and the browser question.
Learn moreBrowser Extensions
A companion extension is a common second surface for a SaaS product, and a good acquisition channel.
Learn moreTell Us What You Are Selling and to Whom
Send us the product idea and the plan for who pays for it — we will come back with a scope, a phase plan and a budget range within two business days.