Architecture
Account boundaries, networks and topology: the decisions that are expensive to change later.
What we write about, and why
This blog exists to make one phrase mean something concrete: production-ready. Every post takes one property of a production system and shows what it costs to have it, and what it costs not to.
The premise
Software got easy to build and hard to run. Most teams reach production by accident: the prototype works, the MVP ships, and security, observability, recovery and compliance are added later, each one after it was already needed. BuiltForProd treats production as a standard instead of a phase — eight properties designed in from the start.
That standard is public, and so is the reasoning behind it. This blog is where the reasoning gets written down: the account boundaries, the credential model, the restore drill, the review gate, the evidence an auditor asks for. If a post cannot be acted on by someone who will never be our customer, it is not finished.
The eight properties
Every post maps to at least one of these. They are the same eight the Standard defines, and the same eight our own work is reviewed against.
| Property | What it means | The test |
|---|---|---|
| Secure | It protects identities, data, workloads and supply chains. | Is it secure by default? |
| Reliable | It keeps operating through expected failures. | What happens when something fails? |
| Observable | Its state and behavior are visible to operators. | Can operators see what is happening? |
| Scalable | It grows predictably without architectural failure. | What happens when demand grows 10x? |
| Automated | Provisioning, deployment and validation repeat without heroics. | How much depends on manual intervention? |
| Recoverable | Recovery is engineered and tested, not assumed. | Can the system actually be restored? |
| Compliant | Controls and evidence can be demonstrated on demand. | Can controls and evidence be demonstrated? |
| Operable | A second engineer can run it, safely, at 3 AM. | Can another engineer operate it safely? |
Subject areas
Compliance
Controls, evidence and audits, treated as an output of infrastructure rather than a project.
Reliability
Failure you planned for, recovery you have rehearsed, and the difference between the two.
Security
Identity, credentials, guardrails and the boundaries that hold when something goes wrong.
Editorial rules
- Every post opens with a definition that stands on its own, so a reader who arrives from a search result knows within one paragraph whether to keep reading.
- Concrete numbers describe a real system and say which one. A figure from the AWS Enterprise Baseline is labeled as the AWS Enterprise Baseline, never generalized to another cloud.
- We name trade-offs, including the ones that make our own work harder, and we say plainly when a reader should not do the thing the post describes yet.
- We attack patterns, not companies. Alternatives are described fairly, and where one of them is the better choice, the post says so.
- No invented customers, no testimonials we cannot attribute, no benchmark we cannot show the workings for, and no claim that a control exists when it does not.
- Corrections are made in place and dated, and the post carries the updated date at the top.
Pitch a topic
The best posts here started as a question someone was living with: a security questionnaire they could not answer, a restore nobody had tried, a deploy that only one person could run. If that is you, send the question rather than the keyword.
Useful pitches say three things:
- The situation. What you are running, and what forced the question.
- The decision you are stuck on, stated as a question with more than one defensible answer.
- What you have already read, and why it did not settle it.
We reply to every message. If we do not know the answer well enough to write it, we will say so, and usually point at someone who does.
Questions
Who writes these posts?
The BuiltForProd engineering team writes them, drawing on the systems we build and hand over. Posts are published under the BuiltForProd byline because they are reviewed by more than one engineer before they ship.
Is this blog a product pitch?
No. Every post is written so an engineer can act on it without buying anything. Posts end with a link to what we build, and that is the extent of the pitch.
Where do the numbers in the posts come from?
Concrete figures describe a real system, usually the AWS Enterprise Baseline, and are labeled that way in the text. We do not publish customer counts, testimonials or benchmark numbers we cannot show the workings for.
How often do you publish?
Weekly during a campaign and roughly every two weeks otherwise. Posts are written ahead and scheduled, and the site rebuilds on a schedule so a dated post goes live without anyone pressing anything.
Can I republish or quote a post?
Quote freely with a link back to the original. For a full republication, email [email protected] and we will agree a canonical link so the two copies do not compete in search.
How do I suggest a topic?
Email [email protected] with the question you want answered and the situation behind it. The best pitches are a problem you are living with right now, not a keyword.
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.