Every AI infrastructure company I’ve looked at recently offers some version of the same three deployment shapes: multi-tenant SaaS, single-tenant, and bring-your-own-cloud, where the product runs inside the customer’s account. BYOC is the one enterprise buyers ask for and the one engineering teams underestimate.
I’ve never shipped a BYOC product. What I have done, repeatedly, is build the thing BYOC actually is: a landing zone in an account I don’t own, that has to be secure on day one and operable by someone else on day 400.
The same problem, different logo
A landing zone for a migration answers a fixed set of questions. Account or project structure. Who’s the identity provider and how do groups map to roles. What’s the network boundary and what’s allowed to cross it. Where do logs go, who can read them, how long they’re kept. How does infrastructure get applied, by what identity, from where. What can the operator touch and what can they only observe.
BYOC asks the identical questions, with one twist: the customer’s answers win. Their org policies. Their identity provider. Their network egress rules. Their compliance team reading your Terraform.
That twist is what makes it hard, and it’s exactly the situation a consultant lives in.
What I’ve learned building in other people’s accounts
Design for the strictest tenant, then relax. My default org-policy baseline on GCP, before any workload lands: no public IPs, no service-account keys, domain-restricted IAM, uniform bucket access. Every workload lives under those rules and earns exceptions individually. If your BYOC installer assumes it can create a public load balancer or mint an SA key, the first regulated customer will break it.
Identity is the product surface. Group-based IAM only, mapped from the customer’s IdP. No direct user bindings, ever. Access revoked when the customer’s directory says so. This isn’t nice-to-have; it’s the first thing their security review checks.
Make the network boundary explicit and boring. Private-by-default. Private endpoints for provider APIs. Deliberate, static egress for anything that must leave. On an AWS MAP Mobilize engagement for an urban and infrastructure consultancy in Singapore, most of the design review time went to IPAM, centralised networking, and what counted as an approved path out. It felt slow. It’s the reason nothing surprising happened later.
Stage your Terraform, and give each stage its own identity. A single mega-apply with one god-mode service account is how you get locked out of your own product in a customer tenant. Split it (bootstrap, shared services, workload) and scope each stage’s identity to what it touches. Keyless auth from CI wherever the cloud supports it.
Assume you’ll be diagnosing it without full access. The customer will not hand you owner on their account. Design telemetry that leaves the tenant on purpose, redacted, with the customer’s consent, so support doesn’t mean “please share your screen”.
Where product teams get it wrong
They treat BYOC as a packaging exercise: same Helm chart, different values file. Then the first customer with VPC Service Controls, or a hard egress deny, or an IdP that only speaks SAML, turns into a six-week professional-services engagement.
The teams that get it right treat BYOC as a landing-zone product. Opinionated defaults, explicit trust boundaries, an operator role that can heal the system without owning it, and a runbook the customer’s platform team can follow.
That’s a migration architect’s job description with a product roadmap attached. I’d argue it’s the same job.