A large Indian bank, insurer, manufacturer or government body eventually asks whether your SaaS product can run inside their data centre. Refusing loses a deal that may be worth more than your entire self-serve business. Agreeing casually is worse, because a single-tenant deployment inside somebody else's infrastructure changes your engineering, your support model and your release cadence, and companies that discover this after signing spend two years paying for the discovery.
The first question to settle is whether they want on-premise or whether they want the properties they associate with it — data residency, isolation, control over access, and an audit trail. Frequently a dedicated single-tenant deployment in an Indian cloud region, with customer-managed encryption keys and a clear access model, satisfies the actual requirement. That conversation is worth having properly, because the answer determines whether this is a configuration exercise or a new product line.
Where genuinely on-premise is required, the constraint that reshapes everything is that you cannot see the environment. No access to logs, no ability to reproduce, no telemetry unless they permit egress, and no way to deploy a fix yourself. Every diagnostic your team relies on has to be replaced by something the customer can run and send you. Building that — a diagnostic bundle, a health check, verbose structured logging they can export — is the single highest-value investment in making on-premise supportable.
Then there is version drift, which is where the economics go wrong. Your cloud product is one version; on-premise customers upgrade when they choose, which is rarely. Within two years you are supporting four versions across five customers, each with a slightly different environment, and every bug report begins with establishing which combination you are looking at. The only real defences are a contractual upgrade obligation with a supported-version window, and a genuine commitment to keeping the on-premise build the same artefact as the cloud one rather than a fork.
Price it as the different product it is. On-premise carries deployment effort, environment-specific support, longer release cycles, and the cost of maintaining installability across whatever operating systems and databases customers have. Charging cloud prices for it means subsidising your largest customers with your smallest, which is the wrong direction. It is also legitimate to constrain the offer — a supported reference architecture, specified versions, a named list of prerequisites — rather than promising to run anywhere.
The decision worth making deliberately, before the first deal rather than during it: is on-premise a strategic product line you will invest in, or a one-off accommodation for a single customer. Both are defensible. What fails is treating a one-off as though it were a product, so it never gets the tooling, or treating a product as though it were a one-off, so every subsequent deal is bespoke. Naming which one this is determines whether the second on-premise customer is easier than the first or harder.
