SaaS Development in India: Building the First Version (MVP)

Software as a service means many customers (tenants) use one running system, each seeing only their own data, and paying on a subscription. That adds three foundations to a normal web app: tenant isolation, billing and self-serve onboarding.

The simplest reliable approach for an MVP is one database with a tenant ID on every row, enforced in one place in the code — and, with PostgreSQL, optionally by row-level security policies as a second lock. Separate databases per customer are rarely needed on day one.

Indian payment gateways such as Razorpay support recurring subscriptions. Store the subscription status in your own database, update it from the gateway's webhooks, and decide upfront what happens when a payment fails (grace period, read-only mode, reminder messages).

If every new customer needs you on a call to set them up, you have a service, not SaaS. The MVP needs sign-up, a guided first step and sample data. Everything else can wait.

Start as one well-structured application (a “monolith first”), not microservices. Leave out:

Avani Academy is my own product: a digital question bank, PDF studio and online assessment engine for classes 6 to 12, with about 50,000 questions and answers, used by administrators and teachers. I'm also building a Growth Management System for Math Magic, an online maths classes business in Bangalore — students, fees, leads and Meta Ads in one admin.

Pick a few numbers before launch: how many sign-ups finish onboarding, how many are still active after a month, and how many convert to paid. These say more than page views or feature requests.

Talk to the first customers every week. Their questions show where onboarding is unclear, and the features they ask for repeatedly — not the ones on your original list — should drive the next version. If nobody is using a feature after a month, remove it rather than polish it.