19  Principle Nine — One Product, Many Homes

A question that paralyzes builders of clinical software: should the product be SaaS or on-premise? The debate is usually framed as a single choice, which is a mistake. The correct answer in regulated markets is that the product is one thing, and it lives in several kinds of homes — because customers’ data governance, not your architecture preference, decides where computation may run.

Large pharma will not send patient data to a young vendor’s cloud. Not because they cannot — because their own commitments, to trialists and regulators, make “where does the data live” a question answered by risk committees, not procurement. Meanwhile, a small biotech may prefer SaaS precisely because it has no infrastructure to host anything. A teaching audience wants neither; it wants a five-minute demo with synthetic data.

These are not three products. They are three homes for one kernel — provided the kernel was built with the right separations.

19.1 The separations that make it possible

• Kernel above all. The engines, the comparison machinery, the validation package: pure, environment-agnostic, version-locked. The kernel knows nothing about who is calling it.
• Identity is pluggable. Authentication is an interface, not an assumption. The same product speaks a vendor portal’s tokens in one deployment, an off-the-shelf OIDC provider in another, and a demo mode with synthetic data in a third. A product welded to one customer’s login system is not a product; it is a tenant.
• Data stays put. The pipeline travels to the data, not the reverse. Executing inside the customer’s environment — their VPC, their network share, their governed zone — is not a degraded mode; it is the flagship mode, and it must be designed from day one rather than retrofitted.
• Every home emits the same evidence. Whether a render happens in a public demo or a locked-down customer enclave, it produces the same manifests, the same addresses, the same audit graph. Trust is portable even where data is not.

19.2 The reference deployment

There is a quiet strategic asset in this design: the reference deployment — a real, production instance running inside an organization that has real governance, real users, and real consequences. It is not the product itself, and it must never leak into the product’s code or data. What it leaks is credibility: proof that the kernel survives contact with an actual regulated environment, which no amount of demo polish can substitute for. Vendors without one are describing a theory; vendors with one are describing a Tuesday.

The discipline is keeping the direction of flow honest: patterns, hardening, and lessons flow from the reference deployment into the product; data, credentials, and employer assets never do. That boundary is a red line from Principle Seven, and it is what lets you say “battle-tested in production” without asterisks.

19.3 Why this beats “SaaS-first”

SaaS-first is a fine bet in markets where data is casual. In regulated clinical markets it forfeits the customers with the largest budgets and the longest contracts, then discovers that the remaining segment — small teams willing to upload sensitive data — is small for reasons that are not going away. One-kernel-many-homes is slower to build by a quarter and durable by a decade.

The test. Ask: “If our best prospect demanded that the product run entirely inside their network next month, would that be a deployment exercise or a rewrite?” If the honest answer is “rewrite,” the product’s home is the vendor’s cloud, and the customer is renting a room in it.