Two clients arrived the same month. The first, an early-stage startup running entirely on Lovable.dev and Supabase, wanted to scale, harden the platform against attacks, and cut costs. The second, an established company already on AWS, wanted to make a single overloaded server scalable and reliable without taking the service down.
On the surface these are different engagements — one is “we have no infrastructure,” the other is “our infrastructure has outgrown its setup.” But seen together they are the two opposite extremes of a single axis. And the diagnosis for both is the same: the substrate and workload planes are not cleanly separated.
That sentence is the whole article. The rest is what it means and why naming it first changes how you fix it.
The two planes
Every running system lives on two planes:
- The substrate plane is everything that has to exist before your code can run: compute, networking, storage, DNS, certificates, secrets, the database engine, the mail relay, the load balancer. It is the ground.
- The workload plane is your application itself — the code your team writes, the containers and services that deliver the actual product. It is what runs on the ground.
The health of a system is not measured by which cloud it uses or how modern its stack looks. It is measured by how cleanly those two planes are separated — whether you can rebuild the substrate without touching the workload, and redeploy the workload without rebuilding the substrate.
When the separation is clean, the substrate becomes reproducible (described as code, versioned, auditable) and the workload becomes portable (it runs anywhere the substrate is provisioned). When the separation is missing, every change is risky, every recovery is manual, and “what do we actually have running?” becomes a question nobody can answer with confidence.
Case 1 · A workload with no substrate of its own
This startup did everything right for its stage. They built fast on Lovable.dev for the application and Supabase for the backend. No servers to manage, no infrastructure bill, free tiers all the way down. The product works and has users.
The challenge is structural, not functional. They have a workload, but its substrate was never theirs. It lives inside opaque platform providers (PaaS). There is no network to segment, no database instance to harden, no infrastructure to audit, no configuration to move — because none of it exists as theirs. When the requirement becomes “secure this against attackers” or “reduce cost at scale,” there is nothing to put your hands on. You can’t harden a substrate you don’t own.
So the work here is substrate materialization: an assessment of the code and data they already have, then fabricating a substrate from scratch as Infrastructure as Code — moving from a platform provider to an infrastructure provider, where the network, the database, the secrets and the scaling rules become real, owned, versioned assets. The workload barely changes. The ground underneath it gets built for the first time.
Case 2 · A substrate with no separation
The second case is the opposite picture. This company is already on AWS, with two code repositories — an Angular frontend and a PHP/SugarCRM backend. But all of it runs on a single virtual machine: Apache, Node.js, MySQL, Postfix, and more, all on one host. It is a classic “pet” in the infrastructure sense — a single hand-maintained server that grew organically along with the business, and that is now risky to change because so much depends on it.
Here the substrate exists. What it lacks is separation: it is separated from nothing. The web server, the application runtime, the database, and the mail relay share one operating system, one set of credentials, one blast radius. A database upgrade can take down email. A traffic spike on the frontend competes with SugarCRM for the same CPU. There is no scaling axis, no failure isolation, no clean recovery — because the substrate and the workload are fused into a single object.
So the work here is substrate decomposition: an inventory of everything that machine is actually doing, a written Substrate + Workloads specification that names each function as its own plane, and a phased improvement plan to pull those functions apart — making the system scalable, secure, and reliable without breaking anything or taking the service down for extended periods. The decomposition is incremental by necessity; the service stays live throughout.
One axis, two diseases
Put the two cases side by side and the pattern is unmistakable:
- The first has no substrate of its own. The workload floats on platforms it doesn’t control.
- The second has no separation. The substrate exists but is fused to the workload in a single machine.
These are not unrelated problems. They are the two pathological extremes of the same axis — too little substrate ownership on one end, zero plane separation on the other. And the destination is identical for both: a clean two-plane architecture where the substrate is owned and reproducible as code, and the workload runs on top of it, portable and isolated. Same north star, opposite illnesses.
This is why naming the model first matters. Once you see both clients as points on the substrate/workload axis, the engagement stops being “migrate to the cloud” or “fix the server” and becomes a precise question: which plane is missing, and which separation has to be built?
Why the diagnosis comes first
In both cases the first deliverable is not a server. It is the levantamiento — an assessment that maps what exists today onto the two planes, and a written Substrate + Workloads architecture that defines the target. Only then comes the phased plan: for the startup, fabricating the substrate as IaC; for the established company, decomposing the monolith one function at a time with low-downtime cutovers.
That insistence on a written, auditable architecture before any change is our Glass Box principle in practice: your infrastructure is described as code that belongs to you and that you can read. No opaque platform you can’t inspect, no irreplaceable machine only one person understands. The substrate becomes an asset, not a liability — reproducible, reviewable, and yours.
If your platform sits somewhere on this axis — too much PaaS opacity, or everything crammed onto one box — the place to start is the diagnosis, not the migration. Talk to us about a substrate-and-workload assessment of your stack.