Customer-hosted deployments: questions to ask first

Why customer-hosted deployments get messy fast

Customer-hosted deployments sound straightforward in a sales call. The customer wants the same product, just inside their own environment. To sales, that can sound like a normal launch with a few extra steps.

It usually is not.

The problem starts with split ownership. Your team writes and ships the software, but the customer often controls the servers, network rules, identity setup, backups, patching schedule, and production access. Each side owns part of the outcome. No one owns the full path from user click to system response.

That gap may not hurt on day one. It hurts when something breaks and both teams need each other to move. Your team asks for logs. The customer asks security for approval. Support asks who is on call. Operations asks whether the issue sits in the app or the host. Half a day disappears before anyone gets near the root cause.

In a SaaS setup, one engineer can inspect logs, roll back a release, and test a fix in the same hour. In a customer environment, that same issue may need a ticket, a change request, a maintenance window, and a remote session. The software itself may be fine. The support path is what stalls.

Loose wording makes it worse. Teams agree on "deployment" without saying who installs updates, who keeps dependencies current, who can read system logs, or who answers the first support call. Sales sees a closed deal. Engineering inherits the unanswered questions.

The cost shows up quietly at first. Engineers spend time in meetings instead of building. Small incidents drag across days. Customers get frustrated because they bought software, not a blame loop. Margins shrink because the contract assumed a clean install, not months of shared operations.

Teams that run lean, high-uptime systems learn this early: clear control matters more than extra hardware. If you cannot say who approves updates, who can access logs, and who owns support when production breaks, the deal is already more complicated than it looks.

Who controls the live system

Confusion starts when everyone says they "own production" but means something different. One team pays the cloud bill, another ships the app, and a third enforces internal security rules. If you do not sort that out early, every outage becomes an argument.

Start with a plain ownership map. Name who owns the servers, who owns the application code, and who owns backups. Those are separate jobs. One company may hold all three, or they may be split across several teams.

That split shapes daily work. If the customer owns the servers but your team owns the app, you may fix a bug quickly and still wait hours for someone else to open a firewall rule, rotate a secret, or add disk space. The contract should reflect that.

Write down who can approve production changes. That includes environment variables, network rules, DNS, certificates, secrets, and scaling settings. If every small change needs a customer ticket and a weekly change window, you need to know that before you promise response times.

The same goes for service control. Decide who can restart services, roll back a release, pause a job, or pull traffic away from a broken node. During an incident, teams lose time when they need permission for basic recovery steps.

It also helps to spell out a few roles in plain language. Someone needs to own infrastructure such as the cloud account, servers, networking, and storage. Someone needs to own the application itself: code, builds, releases, and runtime settings. Someone needs to own backups, retention rules, and restore testing. Then you need two more named owners: one for approving production changes and one for taking emergency operational actions.

Extra environments create smaller but expensive fights. After the deal closes, teams start asking for staging, a hotfix sandbox, or a customer-specific test setup. Decide in advance who pays for those environments, who maintains them, and whether they sit inside the base price.

If nobody can answer these questions in one meeting, control is already fuzzy. That usually means slower fixes, weaker accountability, and a support model that cracks under pressure.

How updates and fixes reach production

In customer-hosted deployments, release speed often breaks before the software does. A bug may be easy to fix and still take days to reach production because nobody agreed on who can ship it.

Start with one direct question: can your team deploy fixes, or can only the customer deploy them? Some customers want full control, and that is reasonable. But if they own every release, your response time depends on their process, not yours.

That difference matters most on a Friday afternoon. Your team may have a patch ready, but if the customer deploys only during a weekly change window, the outage can last far longer than anyone expected.

Put the release path in writing. Say who can push code to the live system, what counts as an emergency patch, how fast approvals must happen, who verifies the fix after deployment, and who can trigger a rollback. If those points stay vague, every incident turns into a negotiation.

Emergency patches need their own rule. Security flaws, payment failures, and data corruption should not wait in the same queue as a minor UI issue. Name the people who can approve an urgent release, how they get notified, and what record they need after the fact.

Version lag creates a different kind of pain. One customer stays close to your current version. Another falls six months behind and asks for support on behavior you changed long ago. Decide early how many older versions you will support, which fixes you will backport, and when extra work becomes a paid change.

Rollback also needs more detail than most teams expect. You need to know where the previous release lives, who keeps database backups, and how the team reverses schema changes if the new version fails. If rollback covers only the app code and not the data changes, you may replace one outage with a worse one.

A small example makes the point. A startup promises fast bug fixes during sales talks, but the customer's internal ops team deploys only twice a month. The promise and the real process do not match, so every incident becomes an argument.

Pricing and features usually get careful attention. The release path deserves the same treatment. When patch flow, version support, and rollback steps are clear, support gets calmer and the surprises get smaller.

What access you need for logs and debugging

When the customer runs the system in their own environment, your team loses the easy visibility of a managed setup. Support changes immediately. The first question during an incident is simple: can your engineers see enough data to understand what happened in the first 10 minutes?

Ask for exact access, not a vague promise that "we can send logs if needed." Manual log sharing slows every incident and often misses the one event that matters. Your team should know which application logs, server logs, audit logs, and error reports it can read without waiting for fresh approval each time.

At a minimum, you need read access to the production logs for every service you support, clear retention periods for logs and metrics, a way to export raw data during an incident, and permission to add tracing, health checks, or alert rules when support depends on them.

Retention matters more than many teams expect. A bug that shows up on Friday may need logs from Tuesday. If the customer keeps only 24 hours of data, your engineers will end up guessing instead of diagnosing. Ask how long logs stay available, where they are stored, and whether limits hide useful events.

Tracing and alerts often create friction in customer-hosted deployments. Some customers allow basic logs but block tracing tools, custom dashboards, or external alerts. If your team cannot trace a slow request or set an alert for a growing queue, you may still get blamed for uptime while lacking the tools to protect it. That is a bad deal.

Incident access also needs rules before the first outage. Decide who can approve temporary elevated access, how fast they respond, and whether your on-call engineer can join the customer's incident channel or bridge. If production access needs three approvals and a business-hours ticket, weekend support is mostly fiction.

Picture a common failure. Background jobs stop. The customer sends screenshots two hours later, but the queue logs have already rotated out. With direct read access, seven-day retention, and permission to add tracing, the team could probably find the stuck worker in minutes.

If you cannot see the system, you cannot support it with confidence. It is better to say that early than pretend otherwise.

Where support starts and stops

Support falls apart when everyone uses the same words for different kinds of work. A product bug, a bad firewall rule, and a full disk can all look like "the app is down," but they need different people.

Customer-hosted deployments need a hard line between product support and hosting support. If you do not draw that line before launch, your team will get pulled into server work, network issues, and internal customer politics that you never priced.

One practical rule helps: if your team can reproduce the issue in its own test setup, it is probably a product issue. If the problem depends on the customer's VPN, DNS, certificates, proxies, storage, or cloud account, the customer team should own the first response.

Write that split in plain language. Your team fixes bugs in the shipped product. The customer team runs servers, networks, backups, and system patching. Both sides join incidents that cross those boundaries. Each side should also name one person who owns escalation.

Response time needs the same level of detail. Do not accept "urgent" as a support policy. Define support hours, expected first reply time, and who can declare a severity-one incident. A sales contact should not be able to page engineers at 2 a.m. unless the contract allows it.

Use one communication path during incidents. Decide who talks to the customer ops team, who talks to end users, and who posts status updates. When five people reply in five channels, trust drops fast.

Then spell out the work your team does not include. It feels awkward, but it prevents most future arguments. Common exclusions include customer-specific reports, infrastructure tuning, on-site admin work, support for third-party tools, and cleanup after changes made by the customer's own staff.

This is where a lean operating mindset helps. Oleg Sotnikov often works with teams on exactly this kind of boundary setting, and the pattern is pretty consistent: a short support document written before launch saves far more time than a long argument after go-live.

If the deal still sounds fuzzy after this discussion, pause it. A vague support promise usually turns into open-ended cost.

What the contract needs to say

A customer-hosted deal can go sideways even when the software works. Most of the pain comes from loose promises, vague wording, and silent assumptions. The contract should remove guesswork before the project starts.

Start with deliverables. Name the exact product version, the features included, the environments covered, and what the team will hand over at the end. If the deal includes installation help, migration work, admin training, or deployment scripts, list each item clearly. If it is not written down, someone will treat it as negotiable later.

The contract should also say what setup work your team will do, what runbooks or documents are included, what launch support period comes with the deal, and what sits outside scope. That last part matters more than most teams expect.

Custom work needs tight limits. This is where teams quietly lose months. A customer asks for one small change, then another, and soon the hosted version no longer matches the base product. Separate standard product behavior from custom development. If the customer wants extra work, route it through a change request with a price, an owner, and a timeline.

That change process should be boring and strict. Define who can ask for changes, who approves them, and what happens to deadlines when new work appears. Good contracts treat scope changes as business decisions, not casual support favors.

Security and compliance responsibilities need the same level of clarity. Your team may provide the software, but the customer may control the servers, network, backups, identity system, and patch schedule. Spell out who handles access control, monitoring, incident response, data retention, and audit duties. "Shared responsibility" sounds fine in a meeting. In a real incident, it usually leads to finger-pointing.

Acceptance terms matter just as much. Decide when the project counts as done. That might be a successful production deployment, a passed test plan, or a review window after go-live. Add a rule for what happens if the customer does not review on time. Otherwise, acceptance can drag on for weeks while the system is already live.

This is one place where experienced technical leadership pays for itself. A few clean paragraphs in the contract can save a team from unpaid custom work, support fights, and long approval limbo.

Review the deal before you say yes

Customer-hosted deployments can look manageable in a sales call and still turn into support chaos after launch. The safest fix is simple: hold one joint review before anyone signs, and walk through how the system will run day to day.

Bring engineering, support, security, legal, and the customer team into the same meeting. Do not split this into separate calls. Bad deals usually happen because each group hears only part of the promise.

Start with access. Decide who can reach servers, dashboards, and logs, who approves emergency access, and how long that approval can take. Then move to updates. Decide who installs releases, who can push urgent fixes, and what happens if the customer freezes changes during a security issue. After that, review support. Say who answers the first ticket, what evidence the customer must provide, and when your team joins the incident. End with scope: what the contract includes, what counts as extra paid work, and which failures stay with the customer side.

When the meeting ends, turn every spoken promise into written text. If someone says, "We can usually share logs quickly," replace it with named contacts, access method, and response time. Loose wording is where most of the future arguments begin.

Before launch, run a small incident test. Pick one realistic problem, such as a failed deployment or a full disk, and make both teams follow the real process. Open the ticket, request access, collect logs, and confirm who can restart what. A short drill often exposes the missing VPN rule or the unclear on-call owner.

Legal and engineering also need to approve the same version of the deal. If the contract says your team supports the application, but the runbook assumes the customer manages the database, fix that gap before signature. One mismatch like that can consume weeks of support time.

An outside Fractional CTO can be useful in this review because they usually spot hidden support work quickly. That is much cheaper than learning after go-live that your team owns a system it cannot reach.

Mistakes teams keep making

Teams often say yes because the sale feels close and the customer sounds prepared. The real work starts after signing. With customer-hosted deployments, the common mistake is treating hosting like a checkbox. It changes who controls the system, who sees problems first, and who gets blamed when something breaks.

One mistake is asking for admin access too late. Sales promises a timeline, legal starts reviewing paper, and only then does engineering ask who can actually get the vendor into the server. If the customer has already decided that vendors get no direct access, your team may end up debugging through screenshots, delayed emails, and partial log snippets. A two-hour fix becomes a three-day outage.

Another mistake is promising uptime for infrastructure your team does not run. If the customer's VM runs out of disk, their firewall blocks traffic, or their IT team delays a patch, users still blame the product. The customer will not care that the host sits outside your control. If you do not control the box, do not promise host-level reliability.

Support also gets messy when teams accept vague language. A line like "vendor will help as needed" looks harmless in contract review. Later, it turns into weekend calls about DNS, certificates, backups, proxy rules, and third-party agents you did not install. Product bugs are your problem. Their environment is theirs, unless the contract says otherwise and the price covers it.

Custom integrations create a slower kind of damage. In presales, every request sounds small: one SSO setup, one ERP connector, one reporting export. Six months later, your team supports four one-off integrations that nobody else uses, and every upgrade becomes a custom project. Put limits on what you will build, what you will maintain, and what counts as new work.

A useful rule is this: if the deal asks your team to carry risk, the contract should name that risk and price it. If the customer wants fast support, strict uptime, or unusual integrations, write down the exact conditions. If they resist that level of clarity, the deal often costs more than it pays.

A real sales-cycle example

A small SaaS vendor was closing a deal with a large enterprise buyer. The product worked well in the vendor's cloud, but the buyer wanted a customer-hosted deployment inside its own network. Sales wanted to move fast. Engineering felt uneasy, but nobody had written down the limits.

The first issue showed up in patching. The buyer required every production update to pass an internal approval board that met twice a month. A security fix the vendor could prepare in one day sat in a queue for 12 days. If something went wrong during that gap, the vendor would still get blamed even though the code was ready.

The second issue appeared during an outage. Users saw timeouts, but the vendor could not see full logs. The buyer had locked log access behind its security team, and application logs rotated out after a few hours. Instead of tracing the error in one session, the vendor spent two days asking for screenshots, partial exports, and short notes from people far from the system.

Then support expanded beyond what anyone expected. The contract said the vendor would provide "production support," but it never separated vendor issues from customer issues. Soon the support team was pulled into DNS mistakes, expired internal certificates, firewall rules, and undersized database storage. None of those were product bugs. All of them landed in the same queue.

That kind of deal can still work, but only if the contract says three things clearly: who can approve and install urgent patches, what log and metric access the vendor gets during incidents, and where the vendor's support responsibility ends.

This is the moment when customer-hosted deployments stop being a sales promise and become an operating model. If those terms stay vague, the buyer gets slower fixes and the vendor inherits a support burden it never priced.

Final checks before signature

A customer-hosted deployment can sound settled on a sales call and still become a weekly argument after go-live. Before legal review, make one final pass through four questions: who approves updates, who can see logs, who owns extra admin work, and what the contract actually covers.

If update control is vague, delays are coming. A security fix that takes your team 10 minutes to prepare can sit for days if the customer requires a ticket, a change board, and a maintenance window every time. Write down who approves normal updates, emergency fixes, and rollback decisions.

Logging access needs the same level of detail. If your team promises fast support but can only work from screenshots sent by email, that promise is not real. The access you get has to match the response time you sell.

Check the scope just as hard. Extra server admin work has a way of sneaking into customer-hosted deployments. A few "quick" requests each month can eat real engineering time, especially when the customer runs a stack your team did not choose. Confirm who owns backups, monitoring setup, certificate renewals, patching, and incident response.

For larger deals, it is worth getting one more technical review before you commit. Oleg Sotnikov at oleg.is does this kind of Fractional CTO work, and an outside read on support promises, infrastructure limits, and contract scope can catch expensive mistakes early.

If any answer still sounds fuzzy, stop the deal and rewrite the terms. A slower signature is cheaper than a bad deployment you have to support for years.