What production-ready has to mean
Eight properties, each with a question it has to answer and a mechanism that answers it. Published so you can hold us to it — and hold anyone else to it too.
What the Standard is
The BuiltForProd Standard is a definition of production-ready in eight properties: secure, reliable, observable, scalable, automated, recoverable, compliant and operable. Each one names a question a system has to answer, and each is mapped to controls that ship rather than to intentions. “Production-ready” is otherwise a sales adjective, and adjectives do not survive incidents.
It is not a certification, there is no score, and nothing about it is proprietary. Apply it to a system we never touched. That is the point: most systems pick up production requirements one crisis at a time — security after the first incident, observability after the first outage, compliance after the first audit, recovery after the disaster. A published standard lets you find out before the crisis instead of after it.
Production is the standard.
The eight questions
One per property. Jump to any of them.
-
Secure
Is it secure by default?
-
Reliable
What happens when something fails?
-
Observable
Can operators see what is happening?
-
Scalable
What happens when demand grows 10x?
-
Automated
How much depends on manual intervention?
-
Recoverable
Can the system actually be restored?
-
Compliant
Can controls and evidence be demonstrated?
-
Operable
Can another engineer operate it safely?
Secure
What it means
It protects identities, data, workloads and supply chains.
The system protects identities, data, workloads and the supply chain that builds them — by construction, not by a hardening project scheduled for later. The most common cloud breach path is a long-lived credential, so the strongest version of this property is one where no such credential exists.
The mechanism
- Single sign-on across every account, with no IAM users and no access keys anywhere: a service control policy denies creating them.
- Multi-factor authentication required by policy, and continuous integration federated through GitHub OIDC, so no cloud key is stored in version control.
- Customer-managed KMS keys with annual rotation, TLS 1.2 and above, and WAF on every workload load balancer through Firewall Manager.
- GuardDuty, IAM Access Analyzer and automated remediation of public S3 buckets, all administered centrally from the security account.
How you verify it
Try to create an IAM user. The policy refuses. Then search your pipeline configuration for a cloud access key — there is nothing to find, because there is nothing to leak.
Reliable
What it means
It keeps operating through expected failures.
The system keeps operating through the failures you should expect: an Availability Zone going away, a node dying, a bad change in a neighboring environment. Reliability is mostly a question of what a failure is allowed to reach.
The mechanism
- Centralized egress with NAT in each of three Availability Zones, so the loss of one zone is not the loss of outbound connectivity.
- Production and non-production sit in separate Transit Gateway route domains with the routes between them blackholed. A non-production mistake cannot reach production.
- Four workload accounts built from one template, so staging is structurally the same environment as production rather than a smaller approximation of it.
- In the Web Application Blueprint, production runs three nodes, three database instances and a horizontal pod autoscaler between three and ten replicas.
How you verify it
Read the route tables. If a non-production account can find a path to a production subnet, isolation is a policy document rather than a property of the network.
Observable
What it means
Its state and behavior are visible to operators.
An operator can see what the system is doing and what it just did, without asking the person who built it. Observability is what turns an incident from an investigation into a lookup.
The mechanism
- Organization-wide, multi-region CloudTrail with log file validation, landing in a separate audit account nobody can write over.
- Cross-account observability: metrics, logs and traces flow into the security account, so there is one place to look rather than fourteen.
- Flow logs on all six VPCs, DNS query logging on the apex, production and staging zones, and seven CIS alarms from root account use to CloudTrail changes.
- Five documented attachment points — an SNS topic, an EventBridge bus, a CloudWatch observability sink, the audit archive and pipeline apps — for connecting your own alerting, paging and chat tools.
How you verify it
Ask where the logs for a single production request live, and see whether the answer is a link or a conversation.
Scalable
What it means
It grows predictably without architectural failure.
The system grows in the directions it will actually be asked to grow — more accounts, more teams, more regions, more traffic — without an architectural rewrite at each step. The failure mode this prevents is the structure that made sense at five people.
The mechanism
- One IPAM address plan with capacity for 16 regions and 8 workload stages per region. Continuous integration rejects hardcoded address ranges, so the plan stays the only source of truth.
- A new account is a map entry and a folder: two pull requests. A new region is a folder, and IPAM, the region policy and the tag policy pick it up automatically.
- The code is region-agnostic, verified by switching the home region on a copy rather than by assertion.
- At the workload layer, Karpenter and the horizontal pod autoscaler size capacity to demand, and the data pipeline scales per event with no always-on compute.
How you verify it
Ask what it takes to add an account, and what it takes to add a region. If either answer starts with a meeting, the system is not scalable yet.
Automated
What it means
Provisioning, deployment and validation repeat without heroics.
Provisioning, deployment and validation repeat the same way every time, run by the pipeline rather than by the one person who remembers the order. Automation that only the author can run is a script, not a process.
The mechanism
- The whole foundation is infrastructure as code in OpenTofu and Terragrunt: 34 modules and 48 unit definitions, with no console-only steps to remember.
- Every change is a pull request. The plan is posted as a comment, reviewed, merged, then applied across all 14 accounts in dependency order, with production gated by required reviewers.
- Six guard scripts run before anything applies, including full mock outputs — so a brand-new environment can be planned end to end before a single resource exists.
- Checkov, Trivy, tflint, formatting checks and a private-key detector run on every change, with every pipeline action pinned by commit hash.
How you verify it
Have an engineer who has never seen the repository open a pull request and read its plan. If deployment requires a hero, it is not automated.
Recoverable
What it means
Recovery is engineered and tested, not assumed.
Recovery is something you have engineered and rehearsed, not something you assume will work. The relevant question is never whether backups exist; it is whether anyone has restored one recently.
The mechanism
- A tamper-resistant log archive in a separate account, with 365-day retention and lifecycle rules to colder storage.
- A service control policy prevents stopping or deleting CloudTrail and Config, in every account, including by an administrator.
- The environment is reproducible from code, so rebuilding is a documented procedure rather than an archaeology project.
- Documented state backup and recovery procedures, and drift detection — daily on critical accounts, weekly across all 14 — that opens an issue and reverts nothing silently.
How you verify it
Restore something. Backups you have not restored are assumptions, and the runbooks exist so the first restore is not during an incident.
Compliant
What it means
Controls and evidence can be demonstrated on demand.
Controls exist, and the evidence that they exist can be produced on demand rather than assembled from screenshots the week before the audit. Readiness is a property of the system; certification is a decision your auditor makes.
The mechanism
- 29 AWS Config conformance pack templates. The SOC 2 baseline pack is on by default, with 13 rules mapped to the Trust Service Criteria; 28 more templates are one flag away.
- Documented control mappings for eleven frameworks, four Security Hub standards, and five quick-start profiles for common situations.
- Auditor permission sets with an explicit deny on data reads: auditors can inspect the controls without seeing the contents.
- Evidence sources that produce themselves — Config history, CloudTrail, findings, access analyzer results and pull request history — plus a quarterly snapshot script and a monthly checklist.
How you verify it
Pick one control and ask for the evidence. Time it. That number is the one that shrinks every audit cycle.
Operable
What it means
A second engineer can run it, safely, at 3 AM.
A second engineer can run the system safely, at three in the morning, without the person who built it. This is the property that most often fails quietly, because it looks fine right up until the person who knew leaves.
The mechanism
- Roughly 160 troubleshooting entries, each with the symptom, the cause, the fix and the prevention, plus runbooks and architecture decision records.
- Documentation personalized to your environment: every code sample shows your own namespace, domains, region and account identifiers.
- CODEOWNERS on every sensitive path and a responsibility matrix covering 12 roles across 6 teams, so ownership is written down.
- A handover session your team performs rather than watches — 11 real tasks completed unaided in the AWS edition before sign-off.
How you verify it
Give the runbook to the engineer who did not build the system and let them do the task. If only one person knows how it works, it is not production-ready.
The BuiltForProd test
Would you trust this in production?
Ask it about the system you run today, property by property, and answer honestly. The eight questions above are not rhetorical: each one has a factual answer, and the ones you cannot answer are the work.
Three or more answers of “no” or “I don’t know” usually means there is real work to do. That is not a sales conclusion — plenty of teams find one gap, fix it themselves and never speak to us. If BuiltForProd is not the right fit, we will tell you.
Questions worth asking out loud
- Have we restored a backup in the last 90 days?
- Can we deploy on a Friday without anyone being nervous?
- If our infrastructure lead left next week, would production be fine?
- Could we recreate production from code if we had to?
- Do we know who can read a production secret?
- Could we answer a security questionnaire without guessing?
Questions about the Standard
What is the BuiltForProd Standard?
The BuiltForProd Standard is a definition of production-ready in eight properties: secure, reliable, observable, scalable, automated, recoverable, compliant and operable. Each one names a question a system has to answer, and each is mapped to shipped controls rather than left as an adjective.
Is it a certification?
No, and it deliberately is not. There is no badge, no numeric score and no certification program. It is a published checklist that anyone can apply to any system, including systems we had nothing to do with.
Why eight properties?
Because those are the eight that keep causing production incidents when they are missing. Each one is independent: a system can be secure and unobservable, or automated and unrecoverable, and each of those combinations fails in a way teams recognize.
How do we measure ourselves against it?
Start with the questions on this page, one per property. If you want an outside read, a BuiltForProd Assessment measures your current environment against all eight and returns a prioritized gap list, and the fee is credited toward a Baseline purchase.
Do the examples on this page apply to every cloud?
The mechanisms named here describe the AWS Enterprise Baseline, because naming a real control is more useful than naming a category. The Azure and GCP editions meet the same eight properties using the mechanisms their own architecture frameworks provide.
Everything we deliver is built to these eight properties: the Baseline, the Blueprints that run on it, and the engineers who operate it.
Find out what production would take.
Tell us what you are running and what is coming: a funding round, an audit, a first enterprise customer, a migration. We will tell you what we would build, what it costs, and whether we are the right fit.