Writing software got cheap. Shipping it stayed expensive. The gap between those two costs is where most of a startup’s time, money, and morale go to die. This essay is about why that gap exists and what closing it actually requires.
Three years ago, starting a serious application meant a sprint plan, two engineers, and a quarter. Today it means a laptop, an editor, and a weekend. Cursor closes tickets while you eat lunch. Claude Code writes Postgres clients and FastAPI handlers before the standup ends. Windsurf wires MCP servers in the background. The cost of producing working code has fallen by something close to an order of magnitude, and most teams have responded the obvious way: by producing a lot more of it.
The work that turns that code into something a real company can run on has not moved at all. The cloud bill — the only line item finance can see — has barely budged. The work behind it, the part nobody puts on a roadmap, takes the same sixteen weeks it took in 2019.
The invisible work
Draw it at the same scale. For a typical Series A team going SOC 2: roughly eighteen thousand dollars of cloud spend, and roughly one hundred and sixty-two thousand dollars of engineering time. On the same chart, the cloud line barely registers. The work to make that cloud compliant fills the rest of the page.
That invisible work has a name nobody puts on the roadmap: landing zone wiring, hub-spoke networking, IAM and workload identity, GitOps and CI/CD, monitoring and audit evidence — the slow, grinding work of turning a cloud account into something an auditor and an enterprise customer can both live with. Six categories. Roughly two thousand five hundred and seventy engineering hours — sixteen weeks of full-team work — before a single feature ships to a paying customer.
The complexity of your infrastructure tracks the complexity of your audit, not the complexity of your product.
A “simple” SaaS — web app, API, Postgres, Redis — needs the same landing zone as a complex AI platform with vector DBs and ML pipelines. The invisible work is the same whether you have three services or thirty. Multiply your engineering count by ten and the ratio holds.
Four failure modes
We’ve watched the same story play out four ways. Two of them happen at startups, two inside enterprises. They share a single cause, but the shape is different enough that each one deserves a name.
The most common is the SOC 2 stall. An enterprise customer says they need SOC 2 before signing the order form. The engineering lead quotes four weeks. Six months later, that engineer has burned out, the customer has signed with a competitor, the deal is dead, and the repo is archived. A close cousin is the startup that quietly turns into a platform company on its way to that audit. To check the box, it hires DevOps, then platform engineering. They wire Vanta, configure GitOps, write Terraform modules. Half a year passes before a single new feature ships; the company that started a quarter earlier has, in the meantime, shipped three.
Inside enterprises, the same pressure produces different shapes. A marketing team decides it can’t wait for IT and buys Vercel, Supabase, and OpenAI directly on a corporate card. The Claude Code experiment ships, customers love it, and the customer data quietly leaves the corporate perimeter — outside every audit, outside every log. The shadow-IT spreadsheet gains a line. The slower variant is when IT does try to absorb the work, and simply cannot. Platform engineering is already running the existing business at capacity; the marketing team’s ticket for a Postgres, a Redis, an LLM gateway, and a tracing instance sits in the queue for eight weeks. By week nine the experiment has died on a laptop or escaped onto a credit card. Same two endings as the startup story, refracted through a slower queue.
All four modes share the same root cause: AI demand is outrunning the platform underneath it. At startups, the platform doesn’t exist yet, so there is no safe place to put the work. At enterprises, the platform exists but is saturated, so there is no available place. Whether the failure is shaped like absence or shaped like queue depth, the result on the spreadsheet is identical.
Three things we hold to be true
Software engineering may be the most disrupted job in the world right now. On the platform side, where the disruption ought to be biggest, almost nothing has changed. The platform engineer is still wiring Terraform. The compliance team is still chasing screenshots. The dashboard they both live in was designed for humans in 2015. The dashboard the next decade lives in is an editor with a model inside it, capable of reading code, holding context, and calling structured tools. The platform under that dashboard should run ahead of the editors, not behind them.
First, compliance is part of the runtime, not a quarterly spreadsheet. SOC 2, ISO 27001, NIST AI RMF, HIPAA — these are properties of how the cloud account, the cluster, the service mesh, the deployment pipeline, and the audit trail are wired. They are real on day zero or they are real on day six hundred, depending on whether the platform was built to carry them. If the platform doesn’t carry the controls, every product team has to carry them on its own back, and every team carries them slightly differently.
Second, AI agents are now expected to drive infrastructure, not just describe it. A platform that requires a human to click through a dashboard to provision a Postgres or roll back a deployment is a platform designed for the last decade. The next decade exposes itself as a small library of typed, structured, plan-before-apply tools that Claude or Cursor or Windsurf can call directly. Chat-with-your-infra is a demo. Apply-with-your-infra is the actual product.
Third, engineers ship product, and they are too expensive to ship platforms as a side effect. Spending senior-engineer hours on Terraform modules and Helm values is a tax on every feature the company will ever ship. The right move is to stop paying that tax, and treat the platform under the product as a shared utility that someone else maintains.
What we built
IntraLaunch is a compliant operating environment, deployed into the customer’s own cloud account — Azure first, with AWS and GCP behind it — so customer data, audit logs, and runtime state never leave the customer’s perimeter. The control plane orchestrates; the runtime stays where it belongs.
Underneath, six dependency-tiered layers — identity, network, compute, data services, the platform layer, and DNS — deploy into a fresh subscription in roughly twenty-four hours. mTLS runs by default. Wildcard TLS comes free. The compliance posture is carried by the substrate itself: every control an auditor will ask about is wired into the resources before the customer’s first deploy — every control SOC 2, ISO 27001, NIST AI RMF, and HIPAA will ask about.
Your editor drives all of it. Claude, Cursor, Windsurf can plan a layer, install a service, run a compliance scan, tail logs, roll back, or query the resource graph — without leaving the editor, without clicking through a dashboard. And on the outside, intra publish takes the laptop a developer is already on, to a live URL running on infrastructure an auditor will sign off on, with one command and no Terraform.
The shift
The most credible enterprise tooling is converging on one shape: a shared context graph holds the ground truth, agents reason over it, action flows through typed tools. The graph is the platform. The dashboard, when there is one, is incidental. Foundation Capital calls this the agent-native enterprise. The OpenSRE community has been calling for the same shape on the cloud operations loop for two years.
Glean built the graph for documents and conversations. PlayerZero built it for code and runtime telemetry. Superblocks built it for internal apps. IntraLaunch is building it for the cloud, DevOps, compliance, and observability layer — the part of the stack that has, until now, lived in spreadsheets, Terraform repos, and the heads of three people who left two reorgs ago.
That graph is IntraLaunch. An infrastructure operating system. The substrate crawls itself — every resource becomes a node, every deployment run, every compliance finding, every log stream feeds back into the same graph. The agent’s tools sit on top of that graph, so an agent can plan a layer, scan for drift, query the blast radius, tail logs, roll back — all reasoning over the same shared state.
Without the graph, agents hallucinate. With the graph, they reason.
2026 onward
For most of the last decade, cloud platforms shipped dashboards, forms, webhooks, email alerts, and quarterly audit reports. The interface was the product, and the user was a human clicking through it. The next decade is shaped by a different set of assumptions: engineers open Claude before they open any dashboard; auditors want a queryable evidence vault, signed at the resource, instead of a slide deck of screenshots; the compliance posture is a live state, scanned continuously, with drift surfaced into the same agent loop that fixes it. The platform that fits those assumptions tends to be the one you don’t see — you feel its presence in what you no longer have to do.
That is the company we are building. It is not a SaaS that sits on top of someone else’s cloud. It is the operating environment that sits under the product, in the customer’s own cloud, doing the work that used to take a platform team a year.
The closing
Innovation should ship. Compliance should be a property of the runtime, not a quarterly project. The editor should drive the cloud, and the engineers should ship features. If that future is one you want to build in, we are onboarding design partners now.
— IntraLaunch, May 2026