Swasthya Sarathi
A healthcare-companion platform for Swasthya Sarathi
A website and mobile app development project for a multi-service healthcare companion — helping peop...
Read itMulti-tenant · Subscriptions · Metering
SaaS Product Development
A SaaS product is a business model expressed in software. We build multi-tenant SaaS product development the parts a demo hides — tenant isolation, subscription billing, usage metering, role modelling and self-serve onboarding — so you scale to a hundred accounts without a hundred manual interventions.
- A tenant-isolation model chosen for your customers, not by default
- Subscription billing, proration, dunning and usage metering that reconcile
- Role and permission modelling that survives an enterprise buyer
- Self-serve onboarding that reaches value before the trial expires
What this is
A SaaS product is a business model in software.
A SaaS product is not a web application with a login screen. It is a business model expressed in software, and the parts that decide whether it survives are the ones a demo never shows: how tenants are isolated from one another, how billing meters what customers actually use, how a plan limit is enforced without a support ticket, and how a new customer reaches value on their own before their trial expires. Those are the parts most SaaS builds underinvest in, and they are exactly the parts we treat as first-class.
We do SaaS product development for founders shipping a first version they will not have to rebuild at Series A, and for established businesses turning an internal tool or a services offering into a multi-tenant product. The visible half is the application. The half that decides whether you can raise, scale and sleep is multi-tenancy, subscription billing, role and permission modelling, usage metering, and the operational tooling to run a hundred accounts without a hundred manual interventions.
If what you actually need is a single-tenant internal tool, we will say so and save you the complexity. Multi-tenancy is not free, and building it when one customer will ever use the system is a cost with no return.
- Multi-tenancy and billing as first-class foundations, not later integrations
- Roles, metering and onboarding modelled so enterprise and self-serve both fit
- Operational tooling to run many accounts without manual firefighting
Where SaaS builds go wrong
The failures that surface at exactly the wrong moment.
None of these show up in a demo. All of them show up when you sign your tenth customer, or your first enterprise one.
-
Tenancy bolted on afterwards
A single-tenant app retrofitted with a tenant column under deadline. One missed scope and a customer sees another customer's data — the incident a SaaS business does not survive.
-
Billing that does not reconcile
Upgrades without proration, failed payments with no dunning, usage counted in a spreadsheet. Revenue leaks quietly and nobody can say by how much.
-
A flat user table
No organisations, no roles, no audit trail — until the first enterprise buyer asks for SSO and per-team permissions, and the answer is a rewrite.
-
Onboarding that is an empty room
The trial starts on a blank screen with no data and no path to value. The cohort churns before it ever sees what it paid for.
-
No operational tooling
Every refund, plan change and impersonation is an engineer running a query in production. Support cannot function and the team cannot scale.
-
No product analytics or metering
You cannot see activation, feature usage or where trials stall, so pricing and roadmap are guesses rather than decisions.
The foundation
Multi-tenancy: the decision you cannot cheaply undo.
Multi-tenancy is the decision that is cheapest to make on day one and most expensive to change later, so we make it deliberately. There are three honest models, and the right one depends on your customers, your compliance needs and your scale — not on fashion.
Shared schema with a tenant key is the default: every table carries a tenant identifier and a global scope makes it impossible to query across tenants by accident. It is the cheapest to run and the easiest to build features on, and it suits most products. Schema or database per tenant is what we reach for when customers demand data isolation for compliance, when a large tenant needs to be moved or restored independently, or when noisy-neighbour performance is a real risk. Many mature products end up hybrid — shared schema for the long tail, a dedicated database for the enterprise accounts that contractually require it. We design the isolation boundary so a bug can never leak one tenant\'s data to another, because that single failure is the one a SaaS business does not recover from.
- Shared schema with an enforced global scope for most products
- Database or schema per tenant where compliance or scale demands it
- Hybrid — shared for the long tail, dedicated for enterprise
- Isolation engineered so a bug cannot leak across tenants
What we build
Everything a SaaS product actually needs.
Not a feature list bolted onto a CRUD app. These are first-class parts of a multi-tenant product, in every build.
Multi-tenant core
Tenant isolation enforced at the data layer, tenant-scoped jobs, files and caches, and a boundary tested so cross-tenant access is impossible by construction.
Subscription billing
Plans, trials, proration, dunning and invoices on Stripe or Razorpay, with webhooks verified server-side so grants always match payments.
Usage metering & limits
An events pipeline that meters seats, API calls or storage, reconciles against the invoice, and enforces plan limits in-product rather than by hand.
Orgs, roles & permissions
Organisations and teams as first-class entities, granular server-side permissions, and an audit trail on every privileged action.
Auth & enterprise SSO
Email and social auth for self-serve, with a clean seam for SAML or OIDC single sign-on and SCIM provisioning when an enterprise buyer arrives.
Self-serve onboarding
A first-run experience with sensible defaults and seed data that gets a new tenant to a meaningful outcome before the trial clock runs out.
Operations console
A back office where support can change plans, issue refunds, impersonate safely and read the audit log — so scaling accounts does not mean scaling engineers.
Product analytics
Activation, feature adoption and trial-stall instrumentation, so pricing and roadmap are decisions backed by data rather than guesses.
Scalable, observable infra
Stateless app tier, managed database with backups and point-in-time recovery, and dashboards and alarms so you learn of an issue from a graph, not a customer.
How we build
Foundations first, because they are the expensive things to change.
Every phase ends in something you can log into, bill through, or read — never a status update.
-
01
Product & tenancy discovery
1–2 weeksWe pin down the core job the product does, the customers it serves, and the compliance they demand, then choose the tenancy and billing model deliberately. You leave with a written architecture note, a scope with edges, and a number we will stand behind.
-
02
Tenancy, auth & billing spine
3–5 weeksThe multi-tenant core, the isolation boundary with its tests, organisations and roles, and subscription billing wired to real plans. The unglamorous foundation that everything else safely stands on.
-
03
The core product surface
6–12 weeksThe workflow your customers actually pay for, built in vertical slices and deployed to a staging URL you can hit from your phone. A demo and changelog every second Friday.
-
04
Metering, onboarding & ops
3–5 weeksUsage metering and plan-limit enforcement, the self-serve onboarding flow, product analytics, and the operations console support will live in. The parts that let the business scale past its founders.
-
05
Hardening & launch
1–2 weeksLoad testing, a security pass over the OWASP top ten and the tenant boundary, backups and recovery rehearsed, and a rollback plan agreed before a launch date. Go-live on a Tuesday, dashboards open.
-
06
Hypercare & handover
30 days, then ongoingWe treat your error rate as ours for the first month, tune what real traffic exposes, and hand over runbooks and the architecture log — or stay on for the roadmap on a retainer.
The stack
Proven, multi-tenant-ready, hireable.
Chosen so the product scales, the billing reconciles, and you can staff it in India later without a rescue.
Laravel 12
PHP 8.4
PostgreSQL
Redis
Horizon
Next.js
React
TypeScript
Tailwind CSS
Stripe
Razorpay
SAML / OIDC SSO
Filament (ops)
AWS
Terraform
Docker
GitHub Actions
Sentry
The difference
A SaaS built to last vs a web app with a login.
| Web app + login | PRS SaaS build | |
|---|---|---|
| Tenant isolation | A tenant column and good intentions | Enforced at the data layer, tested against leaks |
| Subscription billing | Manual invoices, no proration | Plans, proration, dunning, reconciled to usage |
| Enterprise readiness (SSO, roles, audit) | Rewrite when the first deal needs it | A clean seam left from day one |
| Onboarding | A blank screen on trial start | A first-run path to value before expiry |
| Running many accounts | An engineer runs queries in production | An ops console support actually uses |
| Knowing what customers do | Guesswork | Activation and usage instrumented |
| You own the code and data | Sometimes, after a fight | Yours from the first commit |
Our engineering bar
Targets we build a SaaS to.
These are engineering gates and design principles we hold ourselves to on every SaaS build — not growth figures we are promising you. They are the difference between a product that scales cleanly to a hundred tenants and one that needs re-founding at the first enterprise deal.
Talk about your product
0
Cross-tenant leaks by design
Isolation enforced at the data layer and asserted in tests, not left to a remembered where clause.
0%
Billing events reconciled
Every metered event ties back to an invoice; grants always match verified payments.
Day 1
Enterprise seam left open
Orgs, roles and an SSO boundary modelled from the start, so the first big deal is a feature, not a rewrite.
0%
Uptime target
Stateless app tier, managed database with point-in-time recovery, alarms before customers notice.
Proof
All case studies
SaaS products running in the real world.
Multi-tenant platforms that bill cleanly, isolate tenants safely and scale past their founders.
FealDeal
E-commerce — Ethnic Fashion
A high-catalogue ethnic-wear storefront for FealDeal
A Shopify storefront for a Surat ethnic-wear label — 200+ SKUs of lehengas, sarees and suits organised by type, colour, fabric and work, wit...
Shopify
Platform
0+ SKUs
Catalogue
Turant Logistics
Logistics & Supply Chain
Cutting order-to-dispatch by 62% for a 400-truck 3PL
A fleet, ePOD and route-optimisation platform built offline-first for drivers in low-connectivity corridors — because the two off-the-shelf...
0% faster
Faster order-to-dispatch on the ops floor
0% shorter
Shorter POD-to-invoice cycle (8.4 days to 19 hours)
Collection by Rehan
E-commerce — Watches & Accessories
A brand-led watch and eyewear store for Collection by Rehan
A Shopify storefront for a Surat watch and eyewear retailer — browsable by gender, brand, style and combo, with predictive search, COD check...
Shopify
Platform
Brand & style
Browse by
It depends on your customers and compliance needs, and it is the decision cheapest to make on day one and most expensive to change later. A shared schema with a tenant key and an enforced global scope is the default: cheapest to run, easiest to build on, and right for most products. A database or schema per tenant is what we reach for when customers contractually demand data isolation, when a large tenant must be moved or restored independently, or when noisy-neighbour performance is a genuine risk. Many mature products end up hybrid. We design the isolation boundary so a bug can never leak one tenant's data into another, because that is the failure a SaaS business does not recover from.
Billing is where SaaS quietly loses money, so we treat it as core, not an integration bolted on at the end. We build on Stripe or Razorpay for plans, trials, proration on upgrades and downgrades, and dunning for failed payments, and we meter usage through an events pipeline that reconciles against the invoice. Plan limits are enforced in the application, so hitting a cap is a clean in-product prompt to upgrade rather than a support ticket. Webhooks are verified server-side so a customer is never charged for a subscription the product does not actually grant.
Isolation is enforced at the lowest layer we can, not left to every developer remembering a where clause. In a shared-schema model every query is automatically scoped to the current tenant, so cross-tenant access is impossible by construction. Background jobs, exports, file storage and cache keys are all tenant-scoped too, because those are where leaks actually happen. We add automated tests that assert a tenant cannot read another tenant's records, and in per-database models the isolation is physical.
We model roles, permissions and organisations properly from the start, because retrofitting them onto a flat user table when your first enterprise deal demands it is close to a rewrite. Organisations and teams as first-class entities, granular role-based permissions enforced server-side, an audit trail on privileged actions, and a clean seam to add SAML or OIDC SSO and SCIM provisioning when a large customer requires them. You do not build all of it on day one, but the data model has to leave room for it, and ours does.
Because in self-serve SaaS the trial is where most revenue is won or lost, and a customer who does not reach value before it expires simply leaves. We design onboarding as a product surface in its own right: a first-run experience that gets a new tenant to a meaningful outcome quickly, sensible defaults and seed data, progress cues, and in-product prompts at the moments that matter. This is the difference between a trial-to-paid rate that sustains the business and one that quietly bleeds every cohort.
A focused first version — multi-tenancy, auth, the core workflow, subscription billing and a basic admin — is typically 14 to 20 weeks from around ₹18,00,000, built so it does not need throwing away at Series A. A broader platform with usage metering, enterprise SSO, granular roles and a full operations console runs 24 to 36 weeks. We deliberately front-load the tenancy and billing foundations, because they are the expensive things to change later, and scope the rest in a paid discovery so the number we give is one we can hold.
Bring us the SaaS you do not want to rebuild at Series A.
Tell us who your customers are, how you will charge them, and the compliance they demand. A senior engineer replies within one business day with a tenancy and billing recommendation, scope, risk and a number.
Proof
Shipped, measured, still running.
MV Tech Education
A course and admissions platform for MV Tech Education
A website development project for a Bihar vocational institute — a course-catalogue and admissions s...
Read itPatna Taxi
A booking-focused taxi website for Patna Taxi across Bihar
A website development project for a Patna and Muzaffarpur cab operator — a fast, mobile-first taxi-b...
Read itRelated services
Web Development
Production web applications built on Laravel, Next.js and Postgres — typed, tested, observ...
ExploreMobile App Development
Flutter, React Native and native apps that hold up offline, on old hardware and on a metro...
ExploreEcommerce Development
Commerce platforms where the checkout converts and the back office reconciles — multi-ware...
ExploreLet's talk saas product development
Bring us the hard version of the problem.
A senior engineer reads every enquiry. You'll get a real answer — scope, risk and a number — within one business day.