Going on-premise when everyone says SaaS-only: who it's for, and who it burns

The advice you'll always hear , almost without exception, is don't ship on-premise. Stay SaaS. Self-hosting turns every customer's server into your problem, and you'll spend your life debugging environments you can't see.

Most of the time that advice is right. I still think you should ignore it sometimes.

I run Motadata. We make IT operations software, and a real chunk of it runs inside customer data centers instead of our cloud. Some of it is air-gapped, with no path to the internet at all. We didn't do that because we enjoy pain. We did it because there's revenue on-prem you cannot win any other way, and because I keep watching founders reach for on-prem for the wrong reasons and get burned. Here's how I separate the two.

SaaS-only is the correct default. Start there.

If you're early and selling to startups or small businesses, offer SaaS and nothing else. I mean it.

Every on-prem install is a snowflake. Different OS, different firewall, different person on the other end who may or may not know what they're doing. You give that up the moment you go cloud-only, and for most products the buyers don't care where the software runs. They care that it works. So don't romanticize on-prem. For the median founder here it's a tax with no return.

The question isn't whether SaaS is the better default. It is. The question is whether your buyer is allowed to use it.

Who on-premise is actually for

The only good reason to ship on-prem is that your customer legally or operationally cannot use your cloud. Not "would prefer not to." Cannot.

Banks are the clearest example. One of our customers is Central Bank of India. In this country, the RBI requires payment system data to stay on Indian soil, full stop. A founder in San Francisco with a beautiful multi-tenant SaaS literally cannot bid on that work. The data isn't allowed to leave the building. That's not a preference you can sell around with a nicer dashboard.

Then there's government. Defense. Telecom cores. Manufacturing plants that run air-gapped because a breach stops the production line, not just a web app. We see this across BFSI, government, and telecom, and the pattern is always the same. These buyers aren't comparing you to a cheaper SaaS competitor. They're comparing you to nothing, because most SaaS vendors can't even get through procurement.

That's the unlock. On-prem isn't a worse version of your product for difficult customers. It's the only key that opens a door a lot of your competitors can't walk through. The contracts are bigger, they're stickier, and they renew, because ripping out on-prem software is genuinely painful for the customer too.

If your market has buyers like this, on-prem isn't a nice-to-have. It's the whole deal.

Who it burns

Now the other side, because this is where founders bleed.

On-prem destroys the founder who offers it for control, or because one loud prospect asked, without pricing the cost that follows. And the cost follows forever. A few things nobody warns you about:

You lose release velocity. Your cloud ships every week. Your on-prem customer is sitting two or three versions back, because they update on their schedule, during their maintenance window, after their change-approval board signs off. Now you're maintaining behavior across versions you'd forgotten you wrote.

You get version sprawl. Five on-prem customers can mean five slightly different live versions, each with its own quirks, each a place a bug can hide.

You go blind. When something breaks in your cloud, you open a terminal and look. When it breaks in an air-gapped bank, you can't SSH in. You're debugging over a screen-share with someone reading you log lines, and sometimes you're not even allowed to see those.

You lose elastic scaling. The thing cloud gives you for free, throwing capacity at a spike, is now the customer's hardware problem and therefore your support problem.

And your sales cycle stretches. On-prem deals come with security reviews, network diagrams, and pilots that run for months. That's fine if the contract justifies it. It's a slow death if it doesn't.

None of this kills you if the deal is big enough and repeatable enough to fund it. All of it kills you if you bolted on-prem onto a $40-a-month plan because someone asked nicely.

The rule I actually use

Say yes to on-prem when three things are true. The buyer can't legally or operationally use your cloud. The contract is large enough to fund a separate release and support track. And the deployment is standardized enough that you're shipping a known thing, not hand-building each install like a craftsman.

Say no when it's one customer's preference rather than a real constraint, when the deal won't cover the ongoing tax, or, the worst reason, when you're using on-prem as a way to dodge building real cloud security. That last one is a trap. If your honest pitch for self-hosting is "your data is safer because it never touches our servers," you don't have an on-prem strategy. You have a security problem wearing a costume.

What I'd tell a founder starting today

Don't offer on-prem on day one. Build SaaS, get it tight, and learn your buyers.

But if you keep hearing "we can't use cloud" from serious, well-funded segments, and you keep walking away from those conversations, pay attention. That's not noise. That's a market your competitors are also being locked out of, and on-prem is how you get in while they can't.

The mistake isn't offering on-prem. The mistake is offering it casually, to anyone who asks, without respecting how much it will ask of you in return. Treat it as a deliberate bet on a specific kind of customer, price it honestly, and it can be the most defensible revenue you have. Treat it as a checkbox and it will quietly eat your roadmap.

SaaS-only is good advice. Just make sure it isn't costing you the customers nobody else can serve.

(If you want the narrower IT-buyer version of this debate, we broke it down in on-premise vs SaaS monitoring separately.)