Self host your product: revenue, support, and risk

Why this gets messy fast

A self-hosting request often starts with a tempting number. One buyer offers a much larger contract than a normal SaaS deal, usually because legal, security, or data rules block a shared cloud setup. That makes the offer hard to ignore.

The trouble starts right after you say yes. When you self host your product for a customer, you rarely ship the exact same thing you run for everyone else. Their environment has its own network rules, identity setup, backup policy, logging tools, and approval process. Even if the app stays the same, the installation around it does not.

That is the point where product work turns into customer work. Your team stops spending all of its time on features and bug fixes. Instead, people answer questions about load balancers, storage, certificates, firewall rules, and why one node cannot talk to another. You are no longer supporting just the software. You are helping run a private environment for each customer.

Then drift starts. Customer A wants SSO one way. Customer B needs a different database version. Customer C refuses outbound internet access. After a few deals, your self-hosted offer can split into several versions of the same product.

The pattern is familiar. Sales sees a large contract. Engineering makes one-off changes to close it. Support inherits a setup nobody else uses. The next release needs custom upgrade work.

That is why one deal can look profitable on paper and still hurt the business six months later. Every release becomes a project: test this environment, adjust that script, explain that breaking change, wait for the customer's ops team, then do it again. If you do not price that work clearly and limit how much each install can vary, the revenue disappears into support hours.

What customers usually mean by self hosting

When a buyer asks if they can self host your product, they may mean three very different things. They might want it on premises in their own data center, in a private cloud account that you manage, or inside their own VPC in AWS or Google Cloud. Those options sound close in a sales call, but they change who owns the day-to-day work.

Some buyers say "self hosted SaaS" when they do not want full control at all. They just want stronger isolation than a shared setup. A separate database, a fixed region, a private network path, or a dedicated cluster may be enough. If you skip that conversation, you can end up quoting an expensive deployment for a problem that needed a lighter fix.

A few practical questions usually expose the real request. Where will the product run: their servers, their cloud account, or your managed environment? Who handles backups, log retention, and monitoring? Who applies patches, rotates secrets, and responds when something breaks? What does their security team want before launch?

That last question matters early. Some companies only need a standard security questionnaire. Others want architecture docs, access rules, penetration testing, or a formal review by their security team. The phrase "self hosting" often hides all of that.

A small example makes this clearer. One customer may ask for on premises, then accept deployment in their own VPC if your team still runs updates and watches the system. Another may block internet access and require local servers, local backups, and local logs. Both customers used the same phrase, but they asked for very different products.

Where the revenue upside is real

The money is real when self hosting solves a buying problem, not when it is just a preference. Some companies will pay more because they need control over data, network access, audit rules, or internal change approval. Your shared cloud product may be good enough for the team using it, but not for the people who sign the contract.

That is where a self-hosted offer can open deals you would lose otherwise. A bank, factory, or healthcare company may reject a shared environment on policy alone. If your product can run inside their setup, the same buyer may approve a much larger annual contract because the risk feels lower on their side.

What they are paying for is usually a mix of things: control over where the system runs, easier internal approval, private network access, and contract terms that fit enterprise purchasing.

The setup fee gets attention, but yearly support is often where the upside compounds. A one-time installation might bring in cash this quarter. Ongoing support, upgrade help, and a maintenance contract can turn that customer into a steady account for years. In many cases, that matters more than the first invoice.

There is a catch. This works best when the offer stays narrow. If you decide to self host your product, set clear limits on what you support, which environments you allow, and how far custom work goes. A tight enterprise package can bring in higher revenue without pulling your main roadmap into five special cases.

That is usually the sweet spot: a small number of larger customers, a higher yearly fee, and an offer controlled enough to stay profitable.

Where support load grows

Support gets harder the moment each customer runs a different setup. In a normal SaaS model, your team learns one environment and fixes problems once. With self-hosted installs, every customer adds a new mix of network rules, proxy settings, storage, certificates, backups, and internal policies.

That changes the work engineers do every day. Instead of fixing only product bugs, they spend hours inside customer systems they did not design and often cannot fully see. A login issue might come from your app, the customer's identity provider, a reverse proxy, or a firewall rule somebody changed last week.

Sales can make this worse without meaning to. A prospect asks, "Can you run it in our private cloud?" Someone says yes to close the deal. After the contract is signed, that promise turns into urgent support work for engineering, because the customer expects help right away.

The extra load usually shows up in the same places: install calls that run much longer than planned, network and DNS problems outside your product, custom scripts for one customer that another customer also wants, release-day issues because one environment behaves differently, and support tickets that need an engineer instead of a support agent.

The hidden part is maintenance. Docs need updates every release. Install scripts need testing. Backup steps, migration notes, and monitoring guides need care too. If your team skips that work for even one quarter, the next customer install gets slower and riskier.

A small number of customers can eat a surprising amount of time. Four enterprise installs with different rules can keep one strong engineer busy almost full time. Monday goes to a broken upgrade, Tuesday to storage permissions, and Wednesday to explaining why a customer's own email server blocks alerts.

If you decide to self host your product, treat support as part of the price, not a side task. Otherwise the revenue looks good on paper while your best engineers disappear into other people's infrastructure.

Why upgrades become a bottleneck

Once you let customers self host your product, upgrades stop being routine and turn into negotiation. Your team may want to ship every week, but each customer has its own change window, internal review, and fear of downtime.

That fear slows everything down. Even a small update can sit for weeks if the customer thinks it might break login, billing, or a custom integration. A release that takes you 10 minutes in your own cloud can take them a month of tickets, meetings, and approvals.

Old installs create a second problem. Your engineers stop working on one current version and start carrying several old ones at the same time. That means more bug triage, more branch management, and more time spent asking, "Which version are you on?" A team might fix an issue in version 8, only to learn that three paying customers still run version 6.

Database changes make this worse fast. Schema updates need a test run on real data, a maintenance window, and a rollback plan that somebody can execute under pressure. If the customer runs the upgrade, your team still gets blamed when it fails. If your team runs it, you now own a slow, hands-on process for every account.

Security patches lose much of their value when customers install them late. A fix only helps after the customer applies it. If one customer patches today and another waits six weeks, you end up with very different risk levels across the same product.

Good CI/CD can reduce some of the pain, but it cannot remove customer hesitation. That is why upgrade policy matters before the first self-hosted deal, not after it.

Who owns security day to day

When a customer asks to self host your product, security becomes shared work. If you leave that split vague, both sides assume the other handles the risky parts. That usually ends with a missed patch, stale credentials, or an alert that nobody sees.

Start with a plain ownership map. Name the owner for the app, the operating system, and every tool around it.

Your team usually patches the product code, bundled libraries, and any migration scripts you ship. The customer usually patches the OS, containers, Kubernetes, database servers, firewalls, and backup tools they run. For third-party tools your product depends on, write down who upgrades them and who tests compatibility. Put one named contact on each side in charge of urgent security work.

Secrets need the same level of detail. Decide where passwords, API keys, certificates, and signing keys live. If the customer stores everything in their own vault, say whether your team ever gets access. If your team keeps any secret for support or licensing, say who rotates it, how often, and what happens when staff changes.

Logs and alerts cause trouble for the same reason: teams assume coverage. Spell out which events the product must log, where logs go, how long the customer keeps them, and who watches alerts outside business hours. If an incident starts at 2 a.m., someone needs clear authority to declare it, contain it, and contact the other side.

Write the support boundary in simple language. Say what your team investigates, what the customer investigates, and when a ticket becomes a security incident. For self-hosted SaaS, that line matters more than most teams expect. If your team supports the app but not the host, say it plainly. If you need shell access to help, say that too, before the deal closes.

A practical way to decide

Some requests sound bigger than they are. A customer asks to self host your product, but what they really want might be a faster security review, tighter data control, or a way to close one internal policy gap. If you treat every request as a full product line, you can lock yourself into months of extra work.

Start by sorting requests into simple buckets. Look at who is asking, how large the deal is, and how fast they need a decision. A large buyer with a clear budget is different from a small team that wants self-hosted SaaS only because it sounds safer.

Then price each part on its own: setup and deployment work, ongoing support, upgrade help and version maintenance, security work that stays with your team, and security work the customer must own.

This keeps one big number from hiding a bad deal. Many teams underprice the install, then lose money for a year on support tickets and manual upgrades.

Keep the first offer narrow. Pick one deployment pattern and stick to it. You might support only one cloud, one database, and one install method. Five enterprise deployment options may win more calls, but they also multiply testing, docs, and on-call pain.

Test the offer with one or two early customers before you announce it broadly. Watch what happens after the first install. How many hours did your team spend? What broke? Did the buyer need hand-holding every week? Those answers matter more than the contract value on day one.

After the first renewal, check margin again. Include support time, upgrade friction, and the cost of delayed product work. If the deal still makes sense, tighten the package and sell it again. If it does not, say no with a clear reason. That is often cheaper than carrying a custom deployment model that drags on every release.

A simple deal example

A mid-sized company likes your app, but its IT team will not use a shared cloud service. They want the product inside their own VPC. They also ask for SSO, audit logs, and an approval flow before any change reaches production.

On paper, this looks attractive. Your usual contract is $18,000 a year. They offer $65,000 if you self host your product for them. That sounds like clear upside until you count the work around the software.

Before the contract even starts, your team takes on work that does not exist in your normal setup. An engineer has to turn the app into a deployable package. Someone has to write install docs that another team can follow without guesswork. Then come security reviews, architecture calls, procurement meetings, and test runs in a staging environment that does not match your own.

A rough first year might look like this:

• 3 weeks of engineering time for packaging, SSO, and audit logs
• 1 week from DevOps for deployment scripts and environment checks
• 10 to 15 hours of founder or product time in calls, reviews, and approvals
• Ongoing support for upgrades, certificate issues, and access problems

Now do the math. If that work costs you $35,000 to $45,000, the deal is much tighter than it first appeared. If the customer also expects fast responses, upgrade help, or custom docs for internal audits, your profit can disappear.

This kind of deal works only when the price reflects the real effort. Charge a setup fee that covers packaging and rollout. Charge annual support for upgrades and issue handling. Put clear limits in the contract on what your team owns after handoff. If the customer wants enterprise deployment options but will not pay for setup and support, the deal is probably too small.

Mistakes teams make

The biggest mistake is saying yes too early. A customer asks for self hosting, the deal looks big, and nobody stops to define what support actually includes.

That turns into late-night messages, weekend upgrade help, and arguments about what counts as a bug. If you do not set support hours, response times, and who handles the customer's infrastructure, the customer will assume you do all of it.

Pricing is the next trap. Teams charge a one-time setup fee for work that comes back every quarter: version upgrades, broken integrations, certificate renewals, backup checks, and environment drift.

A self-hosted deal can look profitable on paper and still lose money six months later. Recurring work needs recurring pricing.

Product focus slips fast when every install becomes its own project. One customer wants a different auth method, another wants a custom deployment script, and a third wants an older database version.

Engineers then leave the main product to handle edge cases for one account. That usually slows roadmap work for everyone else, including the hosted customers who pay you every month.

Security gets messy when the contract stays vague. If the customer runs the servers, who patches the OS, rotates secrets, reviews logs, and responds to incidents?

If nobody names the owner, both sides assume the other side has it covered. That is how small gaps turn into serious problems.

Another common mistake is treating every install as a special case. Teams build one-off deployment steps, custom docs, and hand-made fixes instead of a standard package with clear limits.

A simple rule helps: if you cannot install, update, and support the same way for most self-hosted customers, you do not have an offer yet. You have a custom services business hiding inside a product company.

Quick checks before you say yes

When a customer asks to self host your product, the deal can look bigger than it is. Extra revenue sounds good, but support costs, upgrade friction, and security ownership can eat that gain faster than most teams expect.

Run through five checks before you agree.

• Look at the first year, not the first invoice. Will the deal still make sense after setup calls, custom docs, bug reports from unusual environments, and a few rescue sessions?
• Ask whether one installer can work for most future customers. If every buyer needs different scripts, database changes, or cloud setup, you are not selling a standard option. You are selling custom work.
• Test the upgrade path early. If customers cannot move to the next version without direct engineer help, every release becomes a small services project.
• Write security duties on one page. Say who patches servers, rotates secrets, stores backups, watches logs, and handles incidents. If that page feels hard to write, daily ownership is still unclear.
• Check whether this fits the company you want to build. A team that wants a clean SaaS product can drift into enterprise deployment work one special deal at a time.

One no does not kill the idea. A pile of weak maybe answers usually should.

If pricing covers the support load, the deployment stays repeatable, upgrades are simple, and both sides know who owns security, the offer may work. If not, charge far more or say no. That choice often saves more time than the deal brings in.

What to do next

Treat the first deal like a pilot, not a permanent product line. If a customer wants you to self host your product, resist the urge to promise a full enterprise package on day one.

Keep the offer narrow. Support one deployment model, one database setup, one upgrade method, and a clear support window. Every extra exception will come back as work your team has to carry for months.

Put the hard lines in writing before anyone signs. A short written offer is often enough if it covers the parts that usually turn into arguments later: what the customer pays for the initial install, how upgrades happen and who applies them, who owns backups, monitoring, and incident response, and what support hours are included versus billed separately.

Then track the real effort from the first install. Do the same for the first upgrade, the first production issue, and the first security request. Teams often price the setup and forget the slow drain that starts after launch. A simple time log will show whether self-hosted SaaS is a real revenue line or just custom support with nicer wording.

Be strict about review points. After one or two customers, decide whether this should stay a premium exception, become a standard offer, or stop completely. If upgrades stall, support tickets pile up, or customers expect you to own security on their servers, the answer is usually clear.

If you want an outside review before you commit, Oleg Sotnikov on oleg.is does this kind of Fractional CTO work. A short review of the offer, support model, and infrastructure plan can be useful before you lock pricing, because fixing a bad self-hosted deal after launch usually costs much more than saying no early.