Building SaaS from India has real structural advantages — engineering cost, a large domestic market, and time-zone overlap with both Europe and Asia. It also has specific traps, most of them in billing and compliance rather than in code.
Architecture decisions that are expensive to reverse
Multi-tenancy model
| Model | How it works | Cost to run | Use when |
|---|---|---|---|
| Shared DB, tenant column | One database, every row tagged | Lowest | Default for most SaaS |
| Schema per tenant | Same server, separate schemas | Moderate | Stronger isolation needed |
| Database per tenant | Fully separate databases | High | Enterprise or regulated clients |
The bug that ends SaaS companies: a query that forgets its tenant filter and shows one customer another customer's data. Enforce tenant scoping at the framework or query-builder level so it cannot be omitted by accident — never rely on every developer remembering to add a WHERE clause.
Billing — build it last, design it first
Billing looks simple and is not. Decide these before writing code:
- Per-user, per-usage, or flat tiers — each implies different data you must track from day one.
- Monthly and annual pricing, with proration when plans change mid-cycle.
- What happens on failed payment — grace period, then restrict, then suspend.
- Trials: card required or not, and what happens at expiry.
- GST on domestic sales; export-of-services treatment for international.
- Invoices that satisfy Indian compliance while looking sane to a foreign buyer.
The India-specific parts
- Domestic recurring billing needs e-mandate RBI rules mean auto-debit on Indian cards requires registered mandates. This is a real integration, not a checkbox — plan for it if you sell subscriptions in India.
- International payments need documentation Foreign inward remittance brings FEMA obligations and paperwork. Talk to your CA before you pick a processor.
- Export of services and GST Selling to overseas customers is treated differently from domestic sales. Getting this wrong is tedious to unwind.
- Data residency questions will come Enterprise buyers, Indian and foreign, increasingly ask where data lives. Have an answer and be able to change region if needed.
What to build first
Version one
- The one workflow that delivers your core value
- Sign-up, login, password reset
- Tenant isolation done properly
- One paid plan and one free trial
- Basic usage analytics
- A way for you to support customers manually
Not yet
- Role and permission matrices
- SSO / SAML
- Public API and webhooks
- White-labelling
- Multiple currencies
- An elaborate admin dashboard
Every SaaS founder builds SSO too early. Enterprise customers who need it will tell you — and they will wait, because they always do.
Cost structure to plan for
Infrastructure is usually the smallest of these early on. Founders frequently over-engineer for scale they do not have while under-investing in the support and iteration that actually retains customers.
Operational things that are not optional
- Backups you have tested restoring. Losing customer data is an extinction event for SaaS.
- Uptime monitoring with alerts. You must know before your customers do.
- Error tracking so you see failures users never report.
- Audit logs — enterprise buyers ask, and they help you debug.
- A documented incident process, even if the team is three people.
- Staged deployments so a bad release does not hit every customer at once.
The metrics that actually matter early
Ignore vanity numbers. Watch these:
- Activation rate — what share of sign-ups reach the moment of value?
- Week-4 retention — are they still using it a month later?
- Churn — monthly cancellations, and crucially why.
- Expansion — are existing customers upgrading?
- Support load per customer — a leading indicator of product problems.
Planning a SaaS build and want the architecture and billing decisions scoped properly before committing? Talk to us. See also our MVP guide and scaling guide.