Per-user pricing looks reasonable at the start. ₹400 a user a month, twenty users, under ten thousand a month — nobody argues with that in a budget meeting. Then you open a second unit, and the number moves in the one direction it knows.
The part that gets missed is what the pricing model does to your decisions. When every login has a price on it, you start rationing logins. The store keeper shares a password with the assistant. The night shift uses the supervisor's account. Six months later the audit trail is fiction, because the software's pricing made honest usage expensive.
Three costs that are not on the invoice
1. The growth tax
A per-seat licence charges you more precisely when you are doing well. Seven units instead of four means the same software costs 75% more to run — for software whose cost to the vendor did not change at all. If your headcount is going up, you are signing up to an expense line that rises with it, forever.
2. The customisation wall
Every business has a rule that does not fit the template. A grace period that works differently for the night shift. An approval that skips a level above a certain amount. A payout split when two people referred the same patient.
On rented software you get one of three answers: it is on the roadmap, it needs the enterprise plan, or it cannot be done. On software you own, it is a change request measured in days — because the person who wrote the code can open it.
3. The exit cost
The real question about any system is not what it costs to run. It is what it costs to leave. If your five years of billing history lives in a database you cannot connect to, and the only way out is a report screen with a date filter, you are not a customer — you are a hostage with a subscription. I have written a whole pipeline for a client purely because their platform had no usable export. That story is here.
What owning it actually means
"You own it" is a phrase every vendor uses, so it is worth being specific. Ownership means all four of these, in writing:
- The source code — in your git repository, not a zip file emailed once at handover.
- The database — on your server or your cloud account, with credentials your team holds and backups you can restore without asking anyone.
- The deployment — documented well enough that another developer could take over. If only one person on earth can deploy it, you do not own it.
- No licence key — nothing that expires, phones home, or counts your users.
What you continue to pay for after that is support and new work, at a rate you agree to, and you can stop paying it without the software switching off. That is the whole difference.
Rented software stops when you stop paying. Owned software keeps running while you decide what to do next.
Where renting is the better deal
To be fair about it — SaaS wins outright in a few cases, and pretending otherwise costs clients money:
- Commodity, non-differentiating work. Email, calendars, video calls, accounting for a small firm. Nobody should be building these.
- Genuinely small and stable. Five users, no plans to grow, no unusual rules — a subscription is cheaper than a build, and honest advice says so.
- You need it this week. A build takes weeks. Sometimes the answer is to subscribe now and build later once the process has settled.
The case for owning gets stronger as the process gets more specific to you, and as the user count climbs. Somewhere between those two lines is your crossover point, and it is usually easier to calculate than people expect: annual subscription across all planned users, times three years, against the one-time build plus support.
Everything on this site is built on the owned side of that line — deployed on the client's server, source code handed over, no seat count. More on how that works, or get a number for your case.