Skip to content
Technologies · Products & platforms

A SaaS development company that runs its own SaaS products

We scope, build and operate multi-tenant SaaS: tenant isolation, billing for India and abroad, GST invoicing, SSO and audit logs for B2B buyers, and SOC 2 readiness, shaped by the products we run ourselves.

Startup engineers working together on laptops
At a glance
  • Pooled · bridge · siloedTenancy chosen for your risk, not fashion
  • Razorpay · StripeSubscriptions, mandates and GST invoices
  • SSO · SCIM · audit logsWhat B2B buyers ask for before they sign
  • SaaS we run ourselvesMulti-tenant clinic and lab software, plus GRC and cloud-cost tools
SaaS Development

Most SaaS products struggle with scope and tenancy, not code

A SaaS product is a web application with four extra jobs: keeping every customer’s data apart, charging them correctly every month, letting their admins manage their own users, and proving all of that to a buyer’s security team. Teams that hire a SaaS development company for “the app” and meet the other four later usually end up rebuilding them under deadline.

As a SaaS product development company, we plan those jobs into the first release. We help you cut an MVP down to what a paying customer will use, choose a tenancy model you will not regret, wire up billing for India and abroad, and build on our software development, DevOps and SOC 2 readiness practices. For growth-stage concerns such as cloud cost and platform engineering, see our SaaS industry page.

We also build and run SaaS ourselves: multi-tenant practice software for Indian clinics and labs, plus a GRC platform and a multi-cloud cost tool. The lessons further down this page come from those products.

What we build

SaaS development services

SaaS application development services, from the first scoped release to the enterprise features that unblock larger deals.

SaaS MVP scoping & build

The problem

The feature list grows every week, the launch date slips, and nobody has decided what the first paying customer actually needs.

How we build it

We run a short discovery to cut scope to one core workflow plus sign-up, billing and an admin view, then build it in two-week iterations on production foundations: CI/CD, backups, error tracking and tenant isolation from the first commit.

What you get

  • Prioritised MVP backlog
  • Working product in your cloud
  • Billing and onboarding flow
  • Test suite and CI pipeline

What a SaaS development company should build before your second customer

The first customer forgives almost anything. The second exposes whatever you hard-coded for the first: a logo in a template, a currency, a missing tenant filter. This guide covers the decisions that are cheap on day one and expensive in year two: tenancy, billing, tax, enterprise identity, audit and compliance.

Multi-tenant SaaS architecture: pooled, bridge or siloed

The terms come from AWS’s SaaS guidance and describe how much infrastructure tenants share. Here is what each looks like in PostgreSQL:

ModelIn PostgreSQLIsolationCost per tenantOperationsGood fit
PooledShared tables with a tenant_id column, enforced by row-level security policiesGood, if every query runs under the policyLowestOne schema to migrate and back upMost B2B and SMB SaaS
BridgeOne schema per tenant in a shared databaseBetter: a bad query stays inside one schemaModerateEvery migration runs once per schemaHundreds of tenants, some with custom fields
SiloedOne database or cluster per tenantStrongestHighestMany databases to patch, back up and migrateEnterprise or regulated customers who pay for it

Our default is pooled, with isolation enforced by the database rather than only the application, plus a siloed tier for the few customers who require it. Two PostgreSQL details matter. Table owners bypass row-level security unless you set FORCE ROW LEVEL SECURITY, and with transaction-level connection pooling the tenant must be set per transaction (SET LOCAL), not per connection. Our clinic products use row-level tenancy on MariaDB, which lacks PostgreSQL-style row-level security, so the application’s data layer has to carry the isolation. If you take that route, keep tenant scoping in one place and write tests that deliberately try to read across tenants.

Billing: Razorpay, Stripe or both

  • Razorpay suits Indian customers: UPI, Indian cards, net banking and recurring payments through e-mandates, settled in rupees. Recurring card and UPI payments follow RBI’s e-mandate rules, including pre-debit notifications and extra authentication above a set amount, so renewals need more state than a one-off charge.
  • Stripe suits international customers, with mature subscription billing, invoicing and tax tools. As of October 2026, new Stripe accounts for Indian businesses are invite-only, so plan for an invitation, an overseas entity or another gateway for foreign cards.
  • Both is common: Razorpay for India, Stripe for everyone else, with your app as the source of truth for plans and entitlements.

Whichever gateway you use, keep plans, entitlements and invoice numbers in your own database, process webhooks idempotently, and treat the gateway as a payment rail rather than your billing system. Switching gateways later is then a project, not a rewrite.

GST invoicing and e-invoicing

For Indian customers, each invoice needs your GSTIN, the buyer’s GSTIN on B2B sales, the service code, the place of supply and the right tax split: CGST plus SGST for a customer in your state, IGST for one in another. Exports of services can be zero-rated under a Letter of Undertaking. Credit notes for refunds and downgrades must reference the original invoice.

E-invoicing adds a step. Since 1 August 2023, a business whose aggregate turnover exceeded ₹5 crore in any financial year from 2017–18 must report B2B invoices to the Invoice Registration Portal and print the returned IRN and QR code (Notification 10/2023–Central Tax). From 1 April 2025, businesses with turnover of ₹10 crore or more must report each invoice within 30 days of its date. Even if you are below the threshold today, build invoicing so an e-invoice step can be switched on later through a GST Suvidha Provider or the IRP API. The scope of these rules keeps widening.

SSO, SCIM and audit logs for B2B buyers

  • SSO per tenant. Each customer connects its own identity provider over SAML 2.0 or OIDC, with a tightly controlled fallback admin login.
  • SCIM 2.0 provisioning. When HR removes someone in Okta or Entra ID, their access to your product goes too. Deprovisioning is what security teams actually test.
  • Roles that match the customer’s organisation. Admin, manager and member are a start; most B2B products need per-team or per-branch scopes within a year.
  • An append-only audit log. Who did what, to which record, when and from where, with before and after values, exportable by tenant admins. Include support-staff impersonation, because buyers will ask about it.

SOC 2 readiness

SOC 2 is an attestation report issued by an independent CPA firm against the AICPA Trust Services Criteria. A Type I report looks at control design at a point in time; a Type II report covers how controls operated over a period, commonly several months. The engineering controls (SSO and MFA for staff, logging, backups, change management, vulnerability scanning) are far easier to build in than to retrofit. We help you prepare through our HIPAA, GDPR and SOC 2 practice. The audit itself is done by a firm you choose; we do not certify anyone.

Scoping an MVP that can charge money

  • One core workflow, done well, for one type of customer.
  • Self-serve sign-up and tenant creation, even if you onboard the first customers by hand.
  • Real billing from the start, even with a single plan, so you learn whether people pay.
  • An internal admin view for support, with audited impersonation.
  • Leave out custom roles, white-labelling, a public API and mobile apps unless a paying customer needs them now.

What drives SaaS development cost

  • The size of the core workflow and the number of user roles.
  • Integrations: payment gateways, GST and e-invoicing, WhatsApp, email, and industry systems such as HL7 or ABDM.
  • The tenancy model, and whether some customers need dedicated or regional tenants.
  • Enterprise features: SSO, SCIM, audit export and data residency.
  • Compliance targets such as SOC 2, ISO 27001 or the DPDP Act.
  • Who runs the product after launch: your team, or us under a support agreement.

We quote an MVP as a fixed-scope project after discovery, split into milestones you can stop at.

What running our own SaaS products taught us

  • Tenant isolation bugs are the scariest kind. They rarely sit in the main screens. They hide in exports, reports, search indexes, file-storage paths and background jobs that run without a tenant context. Every job and every cache key should carry the tenant explicitly.
  • Billing is mostly edge cases. Mid-cycle upgrades, failed renewals, refunds after an invoice is issued, GST on credit notes, a customer who moves state. Write those cases down before the happy path.
  • Onboarding emails decide whether trials activate. A sign-up with no obvious next step goes cold. Short, timely emails tied to what the user has and has not done work better than a long drip sequence.
  • WhatsApp delivery is never guaranteed. Templates need Meta’s approval, numbers get mistyped, users block businesses, and Meta charges per delivered message. Track delivery status, fall back to SMS or email, and record consent.
  • Migrations must be idempotent. With many tenants, a migration will eventually fail halfway for someone. It has to be safe to run again, per tenant, without manual clean-up.

How to choose a SaaS development partner

  1. Ask which tenancy model they would choose for you, and why not the others.
  2. Ask how they test tenant isolation, not just whether they have it.
  3. Ask how they handle billing webhooks, retries and failed payments.
  4. Check they know Indian tax and payments if you sell in India, and international billing if you sell abroad.
  5. Confirm that code, cloud accounts and payment-gateway accounts are in your name.
  6. Ask whether they run any SaaS themselves.
  7. Prefer a team that cuts your MVP scope over one that quotes everything on your list.
How we start

A typical first engagement: SaaS discovery and scope

Three to four weeks, fixed scope, ending in a scoped MVP and a written proposal you can take to any team.

Week 1

Discovery

Users, the one workflow they will pay for, the pricing model, compliance needs and integrations. We talk to a design partner if you have one.

Week 2

Architecture & scope

Tenancy model, billing design, stack and hosting written up as short decision records, plus a prioritised MVP backlog.

Week 3

Walking skeleton

Sign-up, tenant creation, a test payment and one core screen running in your cloud.

Week 4

Proposal

Milestones, timeline and a fixed price for the MVP build, or a plan your own team can run.

Senior engineers firstYour first call is with someone who will write the code, not a sales script.
You own everythingCode in your repository, infrastructure in your cloud account, documentation handed over.
We run our own products15 live platforms we build and operate, so we feel production pain too.
Honest about fitIf another stack or an off-the-shelf tool suits you better, we will say so.
FAQ

Questions about SaaS projects

The main drivers are the size of the core workflow, the number of user roles, integrations such as payments, GST e-invoicing and WhatsApp, the tenancy model, enterprise features like SSO and audit export, and compliance goals such as SOC 2. After a short discovery we quote the MVP as a fixed-scope project with milestones. Radiatus does not publish prices or day rates.

A focused MVP with one core workflow, sign-up, billing and an admin view is usually a matter of months rather than a year. Scope is the biggest variable, which is why we spend the first weeks cutting it. Integrations with regulated or legacy systems add time because of partner testing.

Usually not at the start. A pooled model with shared tables and database-enforced isolation is cheaper to run and simpler to migrate. We add a siloed option, a dedicated database for one tenant, for enterprise or regulated customers who need it and will pay for the extra operations work.

Yes. A common setup uses Razorpay for Indian customers, with UPI and e-mandates, and Stripe for international cards, while your application holds plans, entitlements and invoice numbers. Indian invoices need GST handled correctly, and exports of services can be zero-rated under a Letter of Undertaking. As of October 2026, new Stripe accounts for Indian businesses are invite-only.

We build and document the controls SOC 2 expects and help you prepare evidence, but only an independent CPA firm can issue a SOC 2 report, and we do not certify anyone. Building controls such as SSO, logging, backups and change management in early makes the audit far less disruptive.

Radiatus is an independent engineering studio, building since 2021 and registered both in Delaware, USA and as an MSME in India. We deliver remotely to founders and product teams in India and other countries, with site visits by agreement, and we build and run multi-tenant SaaS products of our own.

Have a SaaS idea, or a single-tenant app that needs to become one?

Tell us who pays and for what. We will help you cut the first release to something you can ship and charge for.

Discuss your SaaS product

Other technologies we build with

Last updated