Building a software product to sell is a different discipline from building software for one business to use. The code may look similar; the economics, the architecture, and the failure modes are not. And none of it requires a Bangalore address — we run products from Ujjain that serve customers who have never asked where we are.
Custom software vs a SaaS product
| Custom software | SaaS product | |
|---|---|---|
| Users | One organisation | Many, unknown in advance |
| Requirements | Given to you | You have to discover them |
| Architecture | Single tenant | Multi-tenant, isolated data |
| Success measure | Delivered and used | Retained and paid for |
| Ends at | Handover | Never — it is a business |
If you are building to sell, everything below applies. If you are building for your own operations, you want custom software instead, and you should not pay for multi-tenant complexity you will never use.
What a SaaS build actually involves
- Multi-tenancy — every query scoped to a tenant, with data isolation you can defend. This is the architectural decision that is expensive to change later.
- Authentication, roles, and invitations — customers manage their own users; you do not
- Subscription and billing — plans, trials, upgrades, failed payments, proration, invoices with GST
- Onboarding — the first ten minutes decide whether a trial converts, and this is product work, not marketing
- Admin and support tooling — you will need to see what a customer sees, safely, or every support call becomes a guess
- Usage metering and analytics — what people actually use, which is never what you expected
- Reliability — backups, monitoring, and alerts. When it is down, it is down for everyone at once.
Build the MVP narrow, not small
The usual advice — "build an MVP" — gets misread as "build a worse version of everything". The version that works is narrow: one user type, one workflow, done properly, end to end. Ten customers using one workflow completely will teach you more than a hundred trials wandering across half-built features.
Resist the enterprise features until an enterprise customer is paying for them. SSO, audit logs, and granular permissions are worth building the day someone will sign for them and not before.
What it costs
| Stage | Range | Timeline |
|---|---|---|
| MVP — one workflow, one user type | ₹8L–₹20L | 3–5 months |
| Production v1 — billing, roles, onboarding | ₹15L–₹40L | 5–9 months |
| Scale — integrations, enterprise features | Ongoing | Ongoing |
Then the part founders underestimate: infrastructure, payment gateway fees, transactional email and SMS, support, and continuous development. A SaaS product does not have a finish line — budget it as an operating cost, not a project.
Where SaaS builds go wrong
- Single-tenant architecture retrofitted to multi-tenant. The most expensive mistake available. Decide this on day one.
- Building for an imagined customer. Get one real customer using it before writing the second feature.
- Billing bolted on late. Plans, proration, and failed payments touch everything; design them in.
- No metering. Without usage data you cannot price, support, or prioritise.
- Ignoring performance until it hurts. Every tenant shares the system; one slow query affects everyone.
We have done this ourselves
We do not only build SaaS for clients — we run our own. GuestReport serves hundreds of hotel properties with an authority-side dashboard. StayFlint is a hospitality management platform. ValiDoc is a documentation platform for a regulated industry. That means multi-tenancy, billing, uptime, and support are things we operate, not just implement. See our work.
We build SaaS products from Ujjain and for founders in Indore — with the code and the customer data in your name.
Get the architecture right first
Send us the workflow and who pays for it. We will come back with an architecture note and a phased scope before any commercial conversation.