Getting started
What happens after you buy, what we need from you, and what done looks like. Forward this to the people who will be asked for a mailbox, a domain and a decision.
How an engagement runs
A BuiltForProd deployment is a fixed piece of work with a defined end: your cloud foundation, built in your accounts, handed over to your team with the repositories and the documentation, and then left alone. There is no platform of ours you keep paying to sit behind, and nothing in the delivered code names us.
The stages below are the same for every engagement. What changes is your organization profile, the decisions you make, and which Blueprints are deployed on top.
The stages
-
Purchase and kickoff
The offer is accepted, directly or as a marketplace private offer, and we schedule the kickoff. You meet the engineers who will do the work, not an account manager who will introduce them later.
Your part: Name the people who will hold the platform roles, and the person who can make the decisions below.
-
Organization profile
We collect the values that make the platform yours: the namespace that prefixes every resource name, your domains, your home region, your GitHub organization, the root mailbox and the alert address. Around twenty values in total, each of which appears in hundreds of places in the code.
Your part: Provide the values, and decide the ones that are hard to change later.
-
Repository customization
The base repositories are forked into your GitHub organization and customized against your profile. Every deployment-specific value in the code is tagged, so customization is a sweep through tagged lines rather than a search through unmarked code. Your documentation organization and product entitlements are created at the same time.
Your part: Create the GitHub organization, teams and environments, and give us the access to do the work.
-
Deployment
Our engineers deploy the platform into your accounts in dependency order, phase by phase. In the AWS Enterprise Baseline that is a preparation step followed by eight phases: the state backend, the organization and accounts, the pipeline identity, identity and networking, the security services, DNS, the workload networks, and secrets.
Your part: Approve the quota increases and the DNS delegation, and review the pull requests as they land.
-
Verification
Deployment is not finished when the apply succeeds. A verification pass runs the final checks against the live environment, mapped to the control objectives they evidence, and the pass is run twice so that a check cannot be green by accident.
Your part: Watch the verification run. This is the first look at how the platform reports on itself.
-
Sign-off
The engagement closes against a master checklist of more than eighty items. Among them: zero drift across every account, the bootstrap user deleted, production reviewers configured, alerting delivering to a real inbox, and the documentation entitlements live for your team.
Your part: Walk the checklist with us and sign it off. Anything unchecked stays open.
-
Handover
A working session, not a presentation. Your engineers perform the real tasks unaided while we watch: connecting over the VPN, making and reviewing a change, applying it, promoting a release, resolving a drift issue, rotating a secret, adding a team member, and walking the escalation path.
Your part: Send the engineers who will actually operate this, not the ones who are free that afternoon.
-
Ownership
Our access is removed. From that point no BuiltForProd principal, credential or reference exists in your environment or your code. You own the accounts, the repositories and the decisions.
Your part: Decide whether you want a Managed tier, and start running the day-2 procedures.
What we need from you
Six things your organization owns and we cannot bring.
A management account
The cloud account that will own the organization, with billing set up and nothing running in it. In the AWS Enterprise Baseline the account quota is raised before the member accounts are created, and approval can take up to a day.
A team-owned mailbox
Root email addresses are plus-addressed aliases on one mailbox so that no root access is lost when a person leaves. It has to belong to a team, not an individual, and it has to exist before deployment starts.
A domain
The apex is delegated to the platform and per-stage subdomains are created under it. You keep the registrar and publish one record for signed zones; the internal zone needs nothing from you.
A GitHub organization
The repositories are forked into it. You also create the environments for each stage with required reviewers on production, and the teams that match the code ownership rules, so reviews route by blast radius.
Named people in the roles
Human access goes only through single sign-on groups, and the code assigns permissions to groups that already exist. The documentation models a minimum team of ten across the platform, DevOps, application, data and audit roles.
A handful of decisions
The namespace, the home region, the address plan, which paid switches start on and which compliance packs run. Each one is cheap now and expensive later, which is why we ask before the first apply and not after.
The documentation carries the full list, with the group names, the environments and the tool versions your engineers will need: prerequisites.
The decisions we will ask you to make
A three or four letter abbreviation. It prefixes every resource, bucket, role and sign-on group name.
Set once. Global singletons and the state backend key off it, and the platform is region-agnostic but not region-indifferent.
Every address differs between the available plans, so switching later means rebuilding the network. Chosen once, before the first deployment.
Egress inspection, inter-region peering, the advanced scanners and the client VPN are off by default, each with its price stated beside its switch.
The SOC 2 baseline pack is on by default; the AWS Enterprise Baseline ships 28 more, covering HIPAA, PCI DSS, NIST, CMMC and CIS, one flag away each.
We will recommend, not interrogate
Every one of these has a default we would pick for a team like yours, and we will say which and why. The reason we ask rather than assume is that two of them are expensive to reverse, and finding that out after the first apply is a bad way to learn it.
What done looks like
- Every account plans clean: drift detection finds nothing anywhere.
- No long-lived credential exists, and the bootstrap identity used to start the deployment has been deleted.
- Production applies wait for named reviewers, and production is read-only for everyone outside the lead groups.
- Alerts, findings and pipeline results arrive in an inbox a human reads.
- The verification pass has run twice and passed twice.
- Your engineers have performed the core day-2 procedures unaided, in front of us.
- Your team can reach the documentation, personalized to your namespace, domains, region and account ids.
- BuiltForProd has no access to anything.
Sign-off is a checklist, not a feeling. Anything unchecked stays open, and the engagement is not closed while it is. How-to guides covers what your team runs from that point on.
Where to go from here
- The knowledge base explains the documentation and how your team gets access to it.
- How-to guides lists the day-2 procedures, from deploying a change to adding a region.
- Service levels covers the support tiers, the channels and the escalation path.
- Reading paths by role tells each person on your team which documentation pages to open, in order.
Onboarding questions
What happens after I buy BuiltForProd?
After purchase the engagement runs through eight stages: kickoff, the organization profile, repository customization, deployment, verification, sign-off against the master checklist, a hands-on handover session, and the removal of our access. You own the accounts and the repositories throughout; nothing is ever deployed into infrastructure we control.
What do you need from us before deployment can start?
Six things: a management account, a team-owned mailbox for root aliases, a domain, a GitHub organization, named people in the platform roles, and a small set of decisions including the namespace, the home region and the address plan. Everything else we bring.
How long does the whole thing take?
A complete foundation is delivered in weeks of engineering rather than quarters, and your proposal states the timeline for your engagement. The apply time is small; the calendar is set by your decisions, your quota approvals and your reviews, which is also why a prepared customer finishes noticeably faster.
Who from our side needs to be involved?
One decision maker for the choices that are expensive to reverse, one person with administrative access to the cloud account and the GitHub organization, and the engineers who will operate the platform afterward. The last group matters most: handover only ends when they have performed the real procedures unaided.
What does done look like?
Done means every account plans clean, no long-lived credential exists, production applies wait for named reviewers, alerts reach a real inbox, the verification pass has run twice and passed twice, your engineers have run the core procedures themselves, and BuiltForProd has no access to anything. It is a checklist, and you sign it.
What happens if we need help after handover?
The documentation set stays available to your organization, and BuiltForProd Managed exists for the work you would rather not do yourself, in three tiers from hourly help to embedded engineers. Handover is designed so that Managed is a choice rather than a dependency.
Not bought yet, but want to know what you are signing up for?
This page is the honest version of the delivery plan. Ask us what it would look like for your organization, and we will tell you what we would build and where the work falls on you.