The true cost of building your own landing zone is not the quarter you put in the plan. It is the sum of eleven work streams, only three of which anyone estimates, plus an owner for as long as the company exists. Most teams can build a cloud foundation. The question worth arguing about is what else does not get built while they do.
This post is the honest version of that arithmetic: the work items, the engineer-months, the recurring maintenance, the opportunity cost, and the cases where building it yourself is clearly the right call. No prices, because the figure that decides this is your engineering capacity, not anyone’s invoice.
Why the estimate is always wrong
Landing zone estimates are made from the parts you can picture. Someone sketches the account structure on a whiteboard, someone else draws the VPCs, and the two of them agree it is about a quarter of work. They are right about those two things.
The estimate is wrong because a landing zone is not an architecture. It is a set of properties that have to hold across every account, forever, and properties are finished only when nobody can accidentally break them. That is a different kind of work from drawing boxes, and it is the kind that does not compress.
Three specific errors recur:
- Confusing “deployed” with “done.” Terraform applies cleanly, therefore the network is finished. It is not finished until a second engineer can add a spoke without asking the author what the address plan means.
- Pricing the happy path. The estimate covers creating accounts. It does not cover deleting one, moving one between organizational units, or recovering the one where somebody deleted the role the pipeline assumes.
- Treating documentation as a phase. Documentation is not a phase; it is the difference between an asset and a liability with one maintainer.
What actually has to be built
Here is the full list, with what “done” honestly means for each. The engineer-month ranges are planning estimates for a competent team building from a blank repository — they are not measurements, and your numbers will differ. They are here to make the shape of the work visible, not to be quoted.
| Work stream | Usually scoped | What “done” means | Engineer-months (estimate) |
|---|---|---|---|
| Account structure and organizational units | Yes | The layout survives the first team you did not plan for | 0.5–1 |
| Account factory | Rarely | Adding account fifteen is a pull request, not a project | 1–2 |
| Network topology and address plan | Yes | Routing, isolation domains and egress, with addresses assigned by a system rather than a spreadsheet | 1.5–3 |
| Identity model and permission sets | Partly | Every human role defined, production restricted, joiners and leavers handled in one place | 1.5–3 |
| Preventive guardrails | Rarely | Policies engineers cannot route around and do not want to | 1–2 |
| Centralized logging and the audit archive | Partly | Logs land in an account the logged systems cannot reach, and nobody can turn them off | 1–2 |
| Security services and their findings pipeline | Rarely | Findings reach a human who is expected to act, with severity that means something | 1–2 |
| CI trust and deploy identity | Rarely | The pipeline holds no cloud keys, and its role is scoped to a repository and a branch | 0.5–1.5 |
| Compliance control mapping and evidence | Rarely | An auditor’s question is a query, not a screenshot hunt | 1–2 |
| Documentation, runbooks and onboarding | Rarely | A new engineer ships an infrastructure change in week one | 1–2 |
| Day-2 procedures: drift, upgrades, incidents | Almost never | Drift is detected and triaged; provider and module upgrades have a reviewed path | 1–2 |
Add the ranges and the honest answer is somewhere between eleven and twenty-two engineer-months for a foundation you would defend in a security review. Teams that finish nearer the bottom of that range have usually done it before. Teams that finish above it have usually discovered identity and compliance halfway through.
The line item everybody forgets: it never finishes
A landing zone is not delivered; it is adopted. From the day the first workload lands on it, someone owns:
- Provider and module upgrades. A cloud provider ships breaking changes on its own schedule. Somebody reads the changelog, plans the upgrade, and explains to a reviewer why the diff is safe.
- Drift triage. Something in production does not match the code. Reverting it blindly is how a discrepancy becomes an outage — a point we argue at length in drift is a fact, not a failure.
- Growth. New team, new account. New market, new region. If the address plan was a spreadsheet, the second region is a redesign.
- Evidence. Every enterprise deal now arrives with a security questionnaire. Answering it from the foundation’s own records is cheap; answering it from memory is a week.
- The bus factor. The foundation’s author leaves eventually. What they leave behind is either a documented system or a folklore system.
Call that one to two engineer-months a year in steady state, more in a year with a major version bump or a new region. It is not a large number. It is a permanent number, and permanent numbers belong in the business case.
Opportunity cost is the number that decides it
Engineering capacity is the scarcest thing a scale-up has, and a landing zone consumes it at exactly the wrong moment: after the first enterprise prospect asks for a security review, before the product has won the segment.
Two senior engineers on a foundation for two quarters is roughly a year of senior product engineering that did not happen. Nothing about that year appears in a roadmap, which is why it never gets argued about properly. We made the general version of this argument in production readiness is a velocity multiplier: the tax is real whether or not you choose to see it, and the only choice is whether you pay it as a project or as recurring rework.
There is also a sequencing cost. A foundation built while under deadline pressure gets its expensive properties — identity, guardrails, evidence — deferred, and deferred properties are the ones that are hardest to retrofit. Adding an account boundary later means new identities, new network paths, new logging destinations and a migration window.
Build, buy or hire: the comparison that matters
A worked example, not a customer story: a 300-person B2B SaaS company running in two AWS accounts, with a first enterprise contract contingent on a security review in four months and no platform team. Here is how the three options actually compare for them.
| Build in-house | Buy a foundation | Hire a platform team | |
|---|---|---|---|
| Time to first production workload on it | Two to four quarters | Weeks of engagement time, engagement-specific | One to two quarters before any code exists, then the build |
| Who owns the code afterward | You | You, if the delivery model hands over the repositories | You |
| Engineering capacity consumed | 11–22 engineer-months, from your product team | Review and decision time, plus the handover | Recruiting, onboarding, then the same build |
| Risk concentration | High: usually one or two authors | Lower: the handover is the test of whether your team can run it | High at first: a single hire from a blank repository |
| Fit to strange requirements | Perfect, by construction | Good if the foundation is customized and source-available; poor if it is a black box | Perfect, eventually |
| Ongoing cost | Yours, permanently | Yours, permanently — optionally shared with a service | Yours, permanently, plus salary |
| What it is bad at | Deadlines, and documenting itself | Being the right shape when your constraints are genuinely unusual | Hitting a date that is one quarter away |
| Fails when | The author leaves before the documentation exists | Nobody on your team is made to operate it before handover | The role is open for five months |
The columns are not mutually exclusive, and the strongest pattern for that worked example is usually the third combined with the second: a foundation in place, and the platform hire starting on top of it rather than under it. Their first quarter then goes to developer experience and product-facing platform work, which is what you actually hired them for.
When building it yourself is the right answer
This is a genuine list, not a rhetorical one. Build it yourself when:
- The foundation is the product’s advantage. If you sell infrastructure, run at a scale where standard topologies stop applying, or your margin depends on a bespoke network design, nobody else’s layout will fit and you should not want it to.
- You already have the team and the library. An existing platform team with a maintained internal module library, a working pipeline and a documented review culture is most of the way there. The marginal cost of a landing zone for them is far below the ranges above.
- Your constraints are unusual. Data residency in an uncommon combination of regions, an air-gapped environment, a regulator who dictates topology, a contract that dictates key custody. A standard layout is a starting point that you will spend longer arguing with than replacing.
- You are genuinely still early. A single account with good hygiene is the correct architecture for a five-person company. The mistake is not starting there; it is staying there past the date you knew you should have moved.
- You want the learning, and you have the time to buy it. Building it teaches the team things reading never will. That is a legitimate reason, as long as it is a decision rather than an accident.
And the honest inverse: if your foundation looks like almost every other company’s foundation, building it from scratch is paying full price for a commodity. Your competitive advantage is your application, not your VPC design.
What “buying” should mean, and what it should not
The failure mode of buying is renting. If the foundation is a managed black box, you have swapped an engineering problem for a dependency, and you will discover the terms of that trade during an incident.
The version worth considering has three properties, and they are the ones to test any vendor against:
- The accounts and the repositories are yours. The code lives in your version control, in a language your team can read, and you can change it without asking.
- Nobody keeps standing access. After delivery, no external identity, credential or role should remain. Ask the question directly and ask what removes it.
- The handover is a test, not a presentation. Your engineers should be required to perform real tasks unaided — make a change, review it, apply it, promote it, respond to drift — before anyone calls it delivered.
That is the shape of the BuiltForProd Baseline: a multi-account foundation deployed into your own accounts, customized, with the repositories and documentation handed over. The AWS Enterprise Baseline edition deploys 14 accounts across 2 organizational units and closes with an 84-item checklist, 17 verification checks mapped to SOC 2 controls run twice, and a hands-on handover in which your team performs 11 tasks unaided. The code is source-available under the PolyForm Internal Use License, so your team can read, modify, fork and extend it inside your organization.
The next step, whichever way you go
If you are about to commission a build, do this first: take the eleven work streams in the table above into a room with the two engineers who would do the work, and have them write “done means…” for each row in their own words. The rows they argue about longest are the rows that will overrun.
If you would rather get an outside read on what you already have before committing a quarter to it, that is what the BuiltForProd Assessment is for — a measurement against the BuiltForProd Standard, which is the same eight properties we describe in what production-ready actually means. Pricing is quoted per engagement and starts from the pricing page. And if we are not the right fit for you, we will say so.