# Buyer-hosted deal: review support, upgrades, and security

> Before you accept a buyer-hosted deal, review support limits, upgrade control, and security duties so one contract does not become a second product.

## Why this deal can split your product in two

A buyer-hosted deal can look like one more sales win. In practice, it can create a second version of your product with its own rules, pace, and support load.

In your normal SaaS setup, your team controls the stack. You pick the cloud, the release schedule, the monitoring, the rollback plan, and the support workflow. When the buyer runs the software, that control shifts. Their network rules, approval process, backup policy, security tools, and change windows start shaping how your product works day to day.

That is where the split starts. One customer may need an older database version, a private registry, manual upgrade approval, a separate audit trail, or support only during their business hours. The core product may stay the same on paper, but the way your team builds, tests, ships, and fixes it changes.

Support usually grows after the contract is signed, not before. Your team now has to answer a different class of questions: is the bug in your code, their infrastructure, or the way they set up the install? Even a small issue takes longer when you cannot inspect logs directly or push a quick fix yourself.

A hosted customer might take 15 minutes to help. A buyer-run install can eat half a day because an engineer has to reproduce the issue in a matching environment, wait for access, and explain the same fix to several people.

So the real decision is about time, risk, and ownership. How many extra engineering and support hours will this customer consume every month? What happens when patches are delayed, environments drift, or incident ownership gets muddy? And who controls uptime, backups, access, upgrades, and the final call during an outage?

If you do not settle those points early, the contract turns into an operations burden. You still have one codebase, but you are supporting two products: the one you run and the one the buyer runs under their own conditions.

## What changes when the buyer runs the software

Once the buyer runs the software, your team stops controlling the environment where problems happen. The code is still yours, but the daily reality changes fast. A small issue in your hosted setup can turn into a long email thread when someone else owns the machines, the network, and the access rules.

Most of the split is operational. The buyer usually controls servers, storage, networks, and system access. They often manage user accounts, VPN rules, and firewall changes too. Backups may belong to the buyer, but your team still gets asked about recovery. Monitoring can be shared, which sounds reasonable until alerts go to the wrong people.

That last part causes more friction than most teams expect. In a normal SaaS setup, your team sees outages first because your alerts fire before customers notice. In a buyer-hosted deal, the buyer's IT team may spot the outage first, or nobody notices until end users complain. Even then, users often blame your product before they blame the buyer's infrastructure.

Debugging also slows down. If your engineers cannot open logs, inspect the database, restart a service, or check system metrics, every incident takes more steps. A bug that would take 20 minutes to diagnose in your own environment can stretch into two days of approvals, screenshots, and scheduled access windows.

Version drift is the other big change. One buyer stays current. Another delays upgrades for six months. A third changes the database version, proxy settings, or backup agent. Now your team supports the same product in several slightly different environments, and each difference can create its own failure mode.

This is why a buyer-hosted deal changes more than deployment. It changes control, response time, and blame. If the contract does not say who owns each part of operations, your team will spend support time arguing about access instead of fixing the issue.

## Write the decision memo first

Before anyone edits contract language, write a one-page memo. It should explain why the buyer wants to run the software on their own infrastructure, what that changes, and what work your team will take on.

Start with the buyer's reason. Sometimes the reason is solid, like internal network rules, data handling limits, or a procurement policy that blocks shared SaaS. Sometimes it is just preference. That difference matters. If the reason is weak, the extra cost and drag may not be worth it.

Buyer-hosted deals often look simple at first. Then small exceptions pile up and become ongoing work. Put every exception from your normal product into the memo, even the awkward ones. Who installs the software? Who owns the runbook? Who handles backups, monitoring, and on-call response? How do upgrades happen, and who tests them before production? What security reviews, audits, and questionnaires will your team have to answer? Which integrations or network rules exist only for this buyer?

After that, break the extra work into separate price lines. Do not hide it inside one annual fee. Support hours, security review time, upgrade testing, patch backports, and custom deployment help all cost different amounts. If you bundle them, the buyer will assume all of it is included forever.

The memo should also force a direct risk call. Mark each issue as accept, change, or reject. "Accept" means you can live with the cost and effort. "Change" means you need tighter contract language, a higher fee, or a narrower promise. "Reject" means the request creates too much support debt or too much security exposure.

Use this memo before legal redlines start. Once lawyers trade versions, people defend positions instead of asking whether the deal still makes sense. A clear memo gives product, engineering, security, and sales one shared view before the contract hardens.

## Set support scope in plain words

A buyer-hosted deal gets messy when both sides assume different things about support. If the customer runs the software on their own servers, your contract needs plain language about who answers, when they answer, and what they will actually do.

Start with the basics. Name the support hours, the contact channel, and the response target for each severity level. Email-only support during business hours is very different from 24/7 incident response by chat or phone. Put numbers in writing. "We reply within 1 business day" is clear. "Fast response" is not.

### What your team covers

Draw a hard line between application problems and buyer infrastructure problems. If your code throws errors after a normal deployment, that is probably your issue. If the buyer misconfigures Kubernetes, fills the disk, breaks DNS, or blocks traffic with a firewall, that is their issue unless you agreed to manage that stack.

A short scope block usually works better than a long legal paragraph:

- Your team supports the app, the documented install steps, and reproducible bugs.
- The buyer supports their cloud account, network, operating system, database hosting, and access controls unless the contract says otherwise.
- Your team reviews logs that the app produces.
- The buyer keeps server logs, backup jobs, and monitoring for their own infrastructure.
- Either side can move out-of-scope work into paid consulting.

Backups and incident triage need the same level of detail. Decide who runs backups, who tests restores, who collects logs first, and who joins the first incident call. If nobody owns those tasks, both sides waste hours trying to prove the problem started somewhere else.

Paid work outside scope should have an easy path. Add a simple rate card or a line that extra work needs written approval. That protects the relationship and stops small favors from turning the deal into a second product that drains your team every week.

If the customer needs more hands-on help, put that into a separate operations or advisory agreement instead of hiding it inside standard support.

## Lock down upgrade rights early

Upgrades turn messy fast when the buyer runs the software. If nobody decides how new versions get approved, every release becomes a small negotiation.

Put the upgrade rules in the contract, not in email. Name one person or team on each side who can approve a release. Your team should control what goes into the release package. The buyer should control when it goes into their test and production environments.

A few rules matter more than the rest. Set a release window, such as monthly or quarterly, so updates do not drift for months. Add a rollback rule with a time limit, clear triggers, and one side that can call for it. Say who tests custom integrations after each update. Set a minimum supported version and how long the buyer can stay behind. And if the buyer wants special branches, backports, or delayed upgrades, price that work in writing.

The integration point often creates the most friction. Your product may work fine after an update, but the buyer's SSO, payment flow, ERP sync, or internal scripts may not. If the buyer owns those integrations, say they test them. If your team built them, say whether normal support covers retesting or whether that work is billed separately.

Do not let the buyer freeze on an old version forever. That sounds harmless at first, then security patches pile up, bug fixes stop matching, and your team starts supporting behavior that no longer exists in the main product. A simple rule works well: support the current release and one earlier major version for a fixed period. After that, support becomes paid best-effort work until they upgrade.

Special branches need their own price. If the buyer wants a custom version, delayed upgrades, or patches for an old release, charge for the extra engineering time. One custom branch can quietly consume as much time as several normal customers.

Teams that handle enterprise software well stay strict here. Oleg Sotnikov often pushes founders to keep one clean release path because it protects both cost and uptime. He makes the same point in his Fractional CTO work: if every upgrade needs a debate, the scope is already too loose.

## Divide security duties without gray areas

In a buyer-hosted deal, security confusion gets expensive fast. If the contract leaves room for guesses, both sides assume the other team handles the risky parts. That is how one enterprise contract turns into endless arguments after the first outage or audit.

Write security ownership by layer, not with vague phrases like "shared responsibility." Each layer needs one clear owner.

The buyer should patch the operating system, virtual machines, network devices, firewall rules, and database engine they run. Your team should patch the application code, bundled services, and third-party libraries you ship. The buyer should control admin accounts in their environment and run access reviews on a schedule. One side should store audit logs for an agreed period, and the other side should get access when an incident starts. One named incident lead should coordinate triage, evidence collection, and customer notices.

Admin access needs plain rules. Name who can create privileged accounts, who approves them, how often the buyer reviews them, and how fast they remove stale access. If your support team needs emergency access, write down how they request it, how long it lasts, and who watches that session.

Audit logs need the same level of detail. Decide which logs matter, where they live, and how long each side keeps them. In most self-hosted software contract disputes, the fight is not about whether logs exist. It is about the logs sitting in the buyer's system, nobody exporting them, and your team not seeing enough to diagnose a breach or prove what happened.

Incident response also needs one leader. If the buyer detects suspicious traffic, who gets the first call? If your team finds an application flaw, who tells the buyer, and who decides whether customers need notice? Put names, roles, and response windows in writing.

Then check every security promise against work your team can actually verify. Do not promise secure infrastructure if you cannot inspect the buyer's servers. Do not promise patching speed for systems you do not control. If your team cannot monitor it, test it, or change it, narrow the promise before you sign.

## A realistic example: one enterprise deal

A SaaS company signs a large annual contract with one enterprise buyer. The buyer wants a private deployment in its own environment, and the revenue looks strong enough to justify the extra work. The team treats it like a sales exception, not a product decision.

Three requests land before the contract closes. The buyer wants VPN access for troubleshooting, a release calendar that follows its internal change window, and weekend support for incidents. None of that sounds huge on its own, so the team says yes to all three.

The trouble starts a month later. The main product ships every week, but the buyer-hosted deal now moves on a slower schedule. One engineer spends Friday nights preparing a separate release package. Support staff keep a weekend phone rotation for one customer. The ops team maintains VPN rules, access logs, and a different runbook just for this deployment.

By month three, the buyer delays an upgrade because it has not finished internal testing. The SaaS team keeps the old version alive "for a few more weeks." That turns into months. Bug fixes now need extra testing in two versions, and some fixes need two separate patches. Revenue still looks good on paper, but the margin is shrinking.

A short memo written before signing could have stopped the drift. It did not need legal language. It just needed clear limits on support hours, upgrade policy, access methods, and the security split. If the buyer pushed back on those points, the team would have seen the real shape of the work before signing.

Teams miss this because enterprise revenue can hide bad fit for a while. One account should not force you to run two release tracks, two support models, and two security playbooks unless the contract pays for that reality.

## Mistakes teams make before signing

The contract often looks familiar, so teams paste their SaaS terms into it and assume the rest will sort itself out. That shortcut creates trouble fast.

In a normal SaaS setup, your team controls hosting, logs, deploys, backups, and monitoring. In a buyer-hosted deal, the buyer controls most of that. If you leave the old language in place, you can end up promising uptime, response times, or recovery work that your team cannot deliver without access.

Security language breaks in the same way. Teams often agree to patching, incident response, or hardening work before they know whether they will get admin access, VPN access, or even useful logs. If the buyer owns the servers and blocks deep access, your team cannot inspect the system properly, test a fix, or confirm what happened after an alert.

Upgrade timing causes another quiet mess. A vague line like "vendor will provide updates" sounds harmless, but buyers often read it as long-term support for old versions, custom backports, and flexible upgrade windows that fit their internal schedule. That can turn one customer release into a separate product branch.

Custom support also gets mislabeled as goodwill. A sales call ends with a few friendly promises: help with deployment, review a script, join one extra meeting, patch one custom workflow. None of that feels big on its own. Together, it becomes an unpaid support tier that engineering has to carry every week.

The last mistake shows up too late: teams do not count the internal load. One self-hosted software contract can pull product, engineering, support, security, and legal into work that does not help the main roadmap.

A simple example makes this clear. A buyer asks for a private install, slower upgrade cadence, and security review help. Sales says yes because the revenue looks good. Three months later, engineers spend Friday nights on buyer-specific issues, support handles tickets for an old version, and product delays shared features for everyone else.

If a deal only works because your team will "figure it out later," the price is wrong, the scope is wrong, or both.

## Quick checks before you say yes

A fast gut check can save months of extra work. If this deal creates new support rules, custom upgrades, or shared security work, you may be building a second product without naming it.

Use a short internal test before you sign a buyer-hosted deal. If your team cannot answer these questions in one meeting, slow down.

1. Is this a true exception or the start of a new offer? One buyer asking for special hosting terms may sound harmless. If the request will likely come up again, treat it as a product decision, not a sales favor.
2. Can one person explain every support boundary out loud? Who handles backups, failed upgrades, slow servers, access issues, and weekend incidents? If the explanation gets fuzzy, the contract will get fuzzy too.
3. What does the cost look like after launch, not just at signing? Extra support hours, custom documentation, security reviews, and upgrade help often turn a good-looking deal into a thin one.
4. Can product keep one release schedule? If this buyer needs delayed upgrades, private patches, or approval before every change, your roadmap may split.
5. Would you sign the same terms for three more buyers? If the answer is no, the terms are probably too custom, too expensive, or too risky.

A simple example helps. Say a buyer wants to host your app in their environment and asks for quarterly upgrades, joint security reviews, and ticket support with a four-hour response time. That may still work, but only if your team can price it, explain it, and repeat it without stress.

This is also where an outside technical advisor can help. Someone who has run product, infrastructure, and enterprise deals can usually spot the hidden second-order cost fast.

## What to do next

A buyer-hosted deal should end with one clear package, not a pile of side promises from calls and email threads. If the memo is solid, turn it into two working documents right away: contract language for the buyer and an internal handoff note for your team.

The contract should say who supports what, who controls upgrades, and who owns each security task. The handoff note should say the same things in plain language, with names, dates, and limits your team can actually follow. If those two documents say different things, the deal will drift the moment the buyer asks for something extra.

Get the same scope approved by the people who will carry the cost after signing. That usually means product, engineering, security, and finance. Product checks whether the request pulls the roadmap off course. Engineering checks whether the deployment, maintenance, and versioning rules are realistic. Security checks the split of duties. Finance checks whether the margin still makes sense six months later, not just on day one.

Before you accept terms, confirm the supported environment, what falls outside support, who can delay or require upgrades, who patches each layer, what the response times are, how paid work outside scope gets approved, and who owns the account after signing. If any line still feels fuzzy, stop and clean it up first.

This is the point where outside review can save real time and money. A good Fractional CTO can read both the contract and the architecture, then spot where support boundaries, upgrade control, or security duties will break in real life. If you need that kind of second pass, Oleg Sotnikov does this through oleg.is as part of his advisory work with startups and small teams. It is most useful before legal language hardens and before sales gives informal yeses that nobody can support later.