When the Cloud Is the Friction

SaaS earned its place by making software easier to buy and use. No installation project, no servers to maintain, no annual upgrade ritual. Open a browser and get on with the work.

That remains a very good default for consumer products and much of the small-business market. But it is not a law of nature. For sensitive or regulated work, especially work involving AI, another hosted service can add more friction than it removes.

The customer is not only evaluating what the software does. They are evaluating a new vendor, a new data processor and a new route out of their security perimeter. They may need legal review, a security assessment, residency guarantees, subprocessor disclosures, identity integration and a new budget line. If they have already standardised on Microsoft, Google, AWS or another large platform, they may also be under pressure to consolidate rather than add tools.

Sometimes the better product is therefore not another destination. It is a capability that runs inside the environment the customer already trusts.

I saw the cost from the engineering side

As a CTO I supported enterprise sales calls rather than driving them, but much of the proof landed with engineering. Security questionnaires arrived early. Pilots needed technical support. Buyers wanted evidence for tenant isolation, access control, retention, deletion, incident response, model-data handling and geographic residency.

Those are reasonable questions. A customer should ask them before sending sensitive information to a smaller vendor. The problem is not unreasonable procurement; it is a mismatch between the value being bought and the machinery required to approve it.

A specialist tool might solve one important problem very well, yet require the customer to assess an entire hosted platform around it. The user sees the capability. Security and procurement have to evaluate the perimeter.

There was another recurring issue. Many organisations had already bought a horizontal AI assistant. A specialist product was not necessarily competing with that assistant—it might do deeper work the general tool could not—but it still looked like one more AI application to approve, provision and remember to use. Explaining the distinction took time, and a useful pilot could still stall because the organisation did not want another vendor in the stack.

That experience changed how I think about deployment. Where software runs is not an implementation detail left until after the product is designed. It can determine whether the customer can buy the product at all.

AI makes the boundary more important

The cloud is not uniquely unsuitable for AI. Hosted models are often the fastest route to strong capability, and I use AI extensively in my own work. The difference is that AI products often touch unusually sensitive source material: contracts, case files, financial records, internal correspondence, operational data or regulated decisions.

They can also introduce another chain of dependency. The application vendor may call a model provider, which runs on infrastructure owned by someone else, under terms and retention settings the buyer also needs to understand. Even when the technical controls are sound, the customer has more parties and more boundaries to assess.

For some work, the simplest answer is to keep the application and its data inside the customer’s environment. If a model is needed, it can use an endpoint the customer has already approved. For other work, the model can help author or configure an artefact and disappear from the production path entirely. The right design depends on the job, but “send everything to our cloud” should not be automatic.

This is partly about privacy and sovereignty. It is also about control. The customer can choose the model, pin a version, manage access through existing identity systems, retain its own audit trail and decide when to upgrade. Those are useful product properties, not merely concessions to a security team.

A few terms worth separating

Several different ideas tend to get bundled together as “on-prem”. They solve different problems.

Customer-hosted software runs in infrastructure controlled by the customer: perhaps their cloud account, Kubernetes cluster or internal servers. It answers the question, “Whose environment is this?”

Air-gapped software runs without a path to the public internet. It is a stricter network condition, usually reserved for work where isolation outweighs convenience.

Bring your own model means the customer supplies the model endpoint and credentials. The application may still be hosted by the vendor, but inference happens under the customer’s existing model agreement and controls.

In-stack software appears inside a platform the customer already uses—an agent, tool or workflow within Microsoft, Google, AWS or another approved surface. It answers a distribution and adoption problem as much as a hosting one.

Local-first means the user’s working data lives on their device and the product remains useful with a poor or absent connection. That is a user-experience and synchronisation architecture, not another name for customer-hosted software.

These choices can be combined. A customer-hosted application can use the customer’s model endpoint. An in-stack tool can invoke a deterministic service inside the customer’s cloud. A genuinely air-gapped product needs local substitutes for every external dependency. The useful question is not “Do you support on-prem?” but “Which boundary is causing the problem?”

Bring the capability to the work

For a narrow specialist product, I increasingly prefer one of two shapes.

The first is deployable software: a container or licensed source installed in the customer’s environment. Their data stays where it already is. The deliverable can be inspected, tested and integrated with the systems they operate today. There is no need to create a parallel customer-data estate simply because that is the conventional SaaS shape.

The second is a capability inside an existing platform. Instead of asking people to adopt another application, the specialist tool is available in the place they already work. Existing identity, access and audit controls can do more of the surrounding work.

Neither approach makes procurement vanish. Customers still need to know what the software does, what it can access, how updates work and who supports it. But the conversation becomes more concrete. Instead of “What happens to our data inside your company?”, the question is closer to “What does this software do inside ours?” That is usually easier to answer with code, tests and explicit boundaries.

It is also a better fit for specialist software. The customer is buying a capability, not being asked to adopt a platform merely so the capability has somewhere to live.

Portability has to be designed in

Shipping the same product into different environments can become an expensive mess. It works only when the parts that vary are kept separate from the part that makes the product valuable.

The central business rules should not know which identity provider, storage service, model endpoint or telemetry system is present. Those external services sit behind explicit boundaries, with adapters selected when the application starts. Supporting a customer environment then means changing the edges, not forking the product or scattering if customer_hosted throughout the code.

The same principle applies to models. OpenAI, Anthropic, Azure OpenAI, Bedrock, a local model or no runtime model at all are materially different choices. The core product should not be inseparable from one of them. Architectural portability does not guarantee behavioural equivalence—a workflow tuned for one model still needs to be tested against another—but it makes that testing possible without a rewrite.

I also favour a small operational footprint. A portable database such as PostgreSQL is available in almost every environment a serious customer is likely to run. Using a few well-understood components is easier to deploy, inspect and support than recreating a web of cloud-specific services for every buyer.

This is conventional domain-driven and hexagonal architecture applied with a commercial purpose. It makes testing easier and infrastructure replaceable, but the larger benefit is optionality. The customer can choose a deployment that fits its constraints without paying for the product to be rebuilt.

The trade-offs are real

Customer-hosted software transfers control to the customer, which means the vendor gives some up too.

You cannot assume access to production telemetry. Diagnosing a problem may require a scrubbed support bundle rather than opening a dashboard. Customers upgrade on their own timetable, so more than one version may need support. Installation and integration need to be repeatable. Documentation, migrations and compatibility promises matter more because a patch cannot be silently deployed overnight.

The commercial model changes as well. Per-seat or usage pricing may make less sense than a licence, implementation fee and maintenance agreement. The customer needs continuity and clear ownership; the vendor needs a support boundary that does not turn every installation into an unlimited operational obligation.

In-stack delivery has a different cost. It reduces adoption friction but gives the host platform influence over the interface, distribution and technical limits. Bring-your-own-model reduces one data concern but does not remove every concern about the application itself. Air-gapped delivery raises the bar for packaging and support substantially.

These are not reasons to avoid the approaches. They are reasons to choose them for a real customer constraint, rather than offering every deployment variation as a feature checklist.

Cloud is a choice, not the product

I am not arguing that cloud-hosted SaaS is over, or that every product should be self-hosted. I am not ruling out building SaaS in the future. For many products, SaaS is still the simplest experience for everyone involved.

The narrower point is that delivery should serve the value of the software. If the customer has to create another security perimeter, move sensitive data and survive months of approval to use one specialist capability, the hosting model may be working against the product.

Good software can meet the customer where the work already happens: in their cloud, against their approved model, inside their existing platform, or on their own device when that is what the problem requires. The cloud is one good place to run it. It does not have to be the thing they are buying.