SaaS & PaaS Product Engineering
Kornspire engineers multi-tenant SaaS and PaaS products: tenancy and isolation models, subscription and usage billing, onboarding, observability and the operational foundations a product needs at scale.
The problem
The single-tenant application that became a product
Most SaaS products begin as one application for one customer. The second customer is accommodated with a configuration flag; the tenth arrives and the shortcuts become the roadmap. Tenancy retrofitted late is expensive and risky — the isolation question reaches into the data model, the query layer, the cache, the background jobs and the audit trail all at once.
Signals you have this problem
- Tenant separation depends on remembering to filter every query
- One customer's data volume or usage spike degrades everyone's experience
- Onboarding a customer takes manual database work
- Billing is reconciled by hand because usage is not metered reliably
Our approach
Decide tenancy, metering and release safety before scale forces the answer
We make three decisions explicit and enforce them in code: the isolation model — shared schema with enforced row-level scoping, schema-per-tenant or database-per-tenant, each with a documented trade-off; the metering model, so that what you charge for is measured at the source; and the release model, so a deployment cannot take every tenant down at once.
Tenancy and isolation architecture
Isolation model selection, enforcement at the data-access layer rather than by convention, per-tenant configuration and noisy-neighbour controls.
Identity and access
Organisation and user models, invitations, role and permission design, SSO and SCIM readiness, and session and token lifecycle.
Subscription and usage billing
Plan and entitlement modelling, metering pipelines, proration and trial handling, payment-provider integration, dunning and invoice records.
Onboarding and activation
Self-service signup, tenant provisioning, sample data, import tooling and the in-product guidance that decides whether a trial converts.
Observability and operations
Structured logging with tenant context, metrics, tracing, alerting on user-visible symptoms, and runbooks for the failures you expect.
Release safety
Migration strategy for live tenants, feature flags, staged rollout, backup and restore rehearsal, and tested rollback paths.
Outcomes
What changes for you
- Tenant isolation enforced by the platform rather than by discipline
- Customers onboarded without engineering involvement
- Revenue that reconciles against measured usage
- Releases that can be rolled out gradually and rolled back safely
Deliverables
What you receive
- Tenancy and isolation design with recorded trade-offs
- Entitlement and billing model documentation
- Provisioning and onboarding flows
- Observability dashboards and alert definitions
- Operational runbooks including restore rehearsal
- Load and isolation test results
Evidence
What you can check before you call
Each item below links to something you can verify yourself — our own product, this website, or the engineering playbook we publish.
- Our product
Upkilo, a multi-tenant SaaS in production
Our own platform for appointment-based businesses, live with paying customers: tenant isolation, per-tenant configuration and multi-location support.
Try it on upkilo.com(opens in a new tab) - Our product
Payments and billing on two providers
Cards, UPI, subscriptions, packages and gift cards through Stripe and Razorpay, with invoices and deposits.
Payments & Billing on upkilo.com(opens in a new tab) - Engineering playbook
ADR-004: how Upkilo isolates tenant data
Why Upkilo uses schema-per-tenant in PostgreSQL, the two alternatives we rejected, and the failure mode that decided it.
Read ADR-004(opens in a new tab) - Engineering playbook
Pattern: multi-tenant SaaS architecture
The reusable architecture we apply to multi-tenant products, written down so it can be reviewed and challenged.
Read the pattern(opens in a new tab) - Engineering playbook
Testing philosophy
What we test, at which level, and what we deliberately do not — the standard a handover is held to.
Read the philosophy(opens in a new tab)
How it runs
The engagement, step by step
- 01
Model the product
Tenant, user, plan and entitlement model; the boundary between product surface and platform surface; the metering points.
- 02
Build the platform spine
Isolation enforcement, identity, provisioning, billing integration and observability — before feature breadth, because retrofitting these is what hurts.
- 03
Deliver product surface
Feature delivery behind flags, with staged rollout and per-tenant configuration where customers legitimately differ.
- 04
Operate and harden
Load and isolation testing, restore rehearsal, cost-per-tenant review, and a security pass before general availability.
- Next.js
- .NET
- Node.js
- PostgreSQL
- Redis
- Kubernetes
- Terraform
- OpenTelemetry
- Stripe and Razorpay
Typical engagements
What this looks like in practice
Illustrative shapes of work rather than client stories. We publish client work only with the client's consent and with real figures, so these describe the problem and the approach instead.
Vertical SaaS for a specific industry
A product built around one sector's workflow and compliance needs, with tenancy, billing and onboarding designed for self-service from day one.
Internal platform offered to partners
An existing internal system turned into a licensed platform: tenant boundaries, external API surface, rate limits and partner-facing documentation.
PaaS building block
A service other teams build on — versioned APIs, quotas, usage metering, sandbox environments and published service-level objectives.
Answers
SaaS & PaaS Product Engineering: questions
What is SaaS and PaaS product engineering?
SaaS and PaaS product engineering is the building and operating of software that is licensed as a subscription service rather than installed per customer, covering multi-tenant data isolation, self-service onboarding, metering and billing, release safety and production operations.
Which multi-tenancy model should we choose?
It depends on the isolation your customers require and the operational cost you can carry. A shared schema with enforced row-level scoping is the cheapest to operate and the most efficient, and suits most products. Schema-per-tenant eases per-customer data export and restore. Database-per-tenant gives the strongest isolation and the highest operational cost, and is usually driven by regulatory or enterprise procurement demands. The decision is recorded with its trade-offs, because it is difficult to reverse later.
Can an existing single-tenant application become a SaaS product?
Yes, and it is common. It begins with an assessment of where tenant identity would have to reach: the data model, every query path, caches, background jobs, file storage, exports and the audit trail. That produces a staged plan — usually enforcing isolation at the data-access layer first, then provisioning, then billing — rather than one high-risk rewrite.
How is usage-based billing kept accurate?
By metering at the source of the event rather than inferring usage afterwards, storing raw metering records immutably, and reconciling aggregates against them on a schedule. Billing disputes are then answerable from data instead of from argument.
Have you actually built and operated a SaaS product yourselves?
Yes. Upkilo is our own product — a multi-tenant booking, CRM, payments and marketing platform for appointment-based businesses such as salons, spas and clinics. We designed it, built it, and we operate, support and license it. That means the decisions described on this page are not theoretical for us: the tenancy model, the billing pipeline, the onboarding flow, the release process and the support cost are all things we have had to get right and then live with.
What does 'ready for enterprise customers' require?
In practice: SSO, provisioning and role mapping, audit logs a customer can export, data residency answers, a documented backup and restore position, published service-level objectives, and a security questionnaire you can complete without improvising. We build towards that list deliberately, because it is what procurement actually asks for.
Deep dives
6 detailed articles on this topic
Longer technical pieces, each covering one specific decision inside this service. Written to be argued with, not skimmed.
Keep reading
Related services
Considering saas & paas product engineering?
Tell us the outcome you need and the constraints you are working inside. You will get a straight answer about whether this is the right service, a smaller one, or none of ours.
Prefer email? hello@kornspire.com