Frequently asked questions
The questions we are actually asked, answered without hedging. If yours is not here, ask us directly and we will add it.
How to use this page
The questions are grouped by what you are trying to decide. Every answer opens with a complete sentence, so you can read one answer without reading the page. Where an answer has more detail behind it, the link goes to the page or the documentation section that carries it.
The product
What we sell and what it is for.
What is BuiltForProd?
BuiltForProd is a production engineering company that builds production-grade cloud foundations, reference architectures for real workloads, and provides the engineers to operate them. It sells three things: BuiltForProd Baseline, the foundation; BuiltForProd Blueprints, production-ready architectures deployed on that foundation; and BuiltForProd Managed, engineers who run production with your team. BuiltForProd is a brand of Nexstella.
What is the BuiltForProd Baseline?
The BuiltForProd Baseline is a multi-account cloud foundation written as infrastructure as code, customized for your organization, deployed into your own cloud accounts by our engineers, and then handed over with the repositories and the documentation. It comes in three editions, the AWS, Azure and GCP Enterprise Baselines, each engineered around that cloud provider’s own architecture framework and all three built to the same BuiltForProd Standard.
What is a Blueprint?
A Blueprint is an opinionated, production-ready reference architecture for a specific workload, delivered as repositories and deployed into the workload accounts of your Baseline. Each one is a working system rather than a diagram: the Web App Blueprint runs a front end and back end on Amazon EKS with DocumentDB, ElastiCache, CloudFront and ArgoCD; the Data and ETL Blueprint is an S3 data lake governed by Lake Formation with Glue jobs and an event-driven Lambda trigger; the Secrets Blueprint encrypts secrets with SOPS under AWS KMS and syncs them to SSM Parameter Store.
What is the BuiltForProd Standard?
The BuiltForProd Standard is the definition of production-ready we build and measure against: secure, reliable, observable, scalable, automated, recoverable, compliant and operable. Each property carries a question a system has to answer, such as whether recovery has actually been tested and whether a second engineer can operate the system safely at 3 AM.
Who is BuiltForProd not for?
BuiltForProd is not the right choice for prototypes, demos and internal experiments with nothing at stake, for teams looking for the cheapest fix to a single symptom, or for teams that want extra hands without adopting a standard. If the root cause of your problem is application code, product design or a data model rather than infrastructure, security, delivery or operations, we will tell you that instead of selling you an engagement.
Delivery
How an engagement runs, from purchase to handover.
What exactly do I receive?
You receive a complete multi-account cloud environment deployed into your own accounts by our engineering team, the customized Git repositories with the full infrastructure code, and the documentation set: architecture decision records, how-to guides, operations runbooks, troubleshooting entries, upgrade guides, compliance material and a reference section. The AWS Enterprise Baseline builds an organization of 14 accounts across 2 organizational units, hub-and-spoke networking, centrally managed identity, security services delegated to a security account, compliance monitoring and a plan-review-apply pipeline.
How long does a deployment take?
A complete foundation is delivered in weeks of engineering, not quarters, and the exact timeline is stated in your proposal because it depends on your prerequisites and decisions. Individual deployment phases run in minutes to about an hour of apply time each; the calendar time is dominated by decisions, quota approvals and your reviews, not by the code.
Do your engineers work inside our accounts?
Yes, during delivery, and through access your organization grants and can remove. The deployment is executed by our engineers into your accounts; after the handover checklist is signed off, that access is removed and no BuiltForProd principal, credential or reference remains in the code.
What happens at handover?
Handover is a working session, not a presentation: your team performs the real tasks unaided while we watch. Connecting over the VPN, making a change, reviewing and applying it, promoting a release, resolving a drift issue, rotating a secret, adding a team member and walking the escalation path. The engagement closes against a master checklist that includes zero drift, the bootstrap user deleted and production reviewers set.
Access and ownership
Who owns what, and what happens after we leave.
Who owns the repositories and the cloud accounts?
You do. The cloud accounts are opened under your organization and the repositories live in your GitHub organization, named to your licensee organization. Ownership of the accounts, the root mailbox, the repositories, the data and the final approval on production changes never moves to BuiltForProd, under any tier.
Does BuiltForProd keep access after handover?
No. After handover BuiltForProd holds no standing access to your environment: no identity principal, no credential, and nothing in the code that names BuiltForProd. If you engage BuiltForProd Managed, engineers work through the single sign-on groups your administrators control, and that access ends the moment you remove them.
Can we modify the code?
Yes. You may deploy, modify, fork and extend the code for your own infrastructure and share it with your employees and contractors, under the PolyForm Internal Use License 1.0.0. What you may not do is resell or sublicense it, publish it, or use it to provide managed services to third parties.
How do we get improvements you make after handover?
Your repositories are forks of the upstream repositories, so you pull improvements through a documented compare, branch, plan, review and merge flow, and your own plan workflow verifies every upstream change before it reaches your main branch. A risk and approval matrix classifies each change, and runbooks exist for upgrades that touch already-applied infrastructure.
Security
The questions a security reviewer asks first.
Are there any long-lived cloud access keys?
No. In the AWS Enterprise Baseline a service control policy denies creating IAM users, login profiles and access keys in every member account; people sign in through IAM Identity Center with multi-factor authentication and 12-hour sessions, pipelines authenticate through GitHub OIDC and assume a deployer role, and workloads use EKS Pod Identity. No AWS key is stored in GitHub.
Who can change production?
Only the platform and DevOps lead groups hold administrative permissions in the production account; every other group is read-only there. Production applies additionally wait for the required reviewers on the production environment gate, and auditors carry an explicit deny on reading data.
How are secrets handled?
Secrets live encrypted in Git with SOPS, one file per application per stage, using a separate key per stage held in the security account, and a sync workflow pushes them into the parameter store as encrypted parameters that the External Secrets Operator delivers to workloads. A developer with write access to the repository still cannot read or change a production secret, because the key policy refuses the request.
Can a compromised account delete its own logs?
No. One organization-wide trail delivers every account’s events, with log file validation, into a separate audit account whose bucket is encrypted, versioned and TLS-only, and a service control policy denies stopping or deleting the trail and the configuration recorder in every member account.
Compliance
What readiness means, and what it does not mean.
Which compliance frameworks does the Baseline support?
The AWS Enterprise Baseline ships controls and evidence sources mapped to SOC 2, HIPAA, PCI DSS 4.0, NIST CSF, CMMC 2.0 and CIS, with a SOC 2 baseline conformance pack on by default and 28 further packs one flag away. Readiness means the controls and the evidence exist; certification is your auditor’s decision, not ours.
Does buying this make us SOC 2 compliant?
No, and anyone who tells you otherwise is selling something. A platform can give you the technical controls, the configuration history and the evidence an auditor asks for; it cannot give you the policies, the training, the vendor reviews or the audit itself. What it removes is the two-week scramble for screenshots.
How does it help at audit time?
Evidence is produced continuously by the platform rather than gathered by hand at audit time: security findings, conformance pack scores, configuration history, the audit trail, access analyzer findings and the pull request history of every change. Auditors are given read-only access with an explicit deny on reading data, so they can verify controls without seeing your customers’ records.
Support
Who helps after the handover session ends.
Is support included with a deployment?
A Baseline or Blueprint purchase is a one-time deployment with a full handover of the repositories and the documentation, and ongoing support is a separate, optional service called BuiltForProd Managed. The platform is deliberately built so that a competent team can run it without us.
What are the Managed tiers?
There are three: On-Demand, which is help by the hour with a 10-hour minimum and no response commitment; Support SLA, a pre-paid annual block of at least 100 hours governed by the service levels in your agreement; and Team Augmentation, dedicated engineers embedded in your team part-time or full-time on a 6- or 12-month commitment.
What are your response times?
Response times are stated in each customer agreement rather than published, because they differ by tier, severity and coverage hours. The terms themselves are fixed: response time is the time to acknowledgment and the start of work, resolution time is the time to a fix or a workaround, and severity is assigned when the request is opened and revised if the facts change.
What does support not cover?
Support covers the platform we delivered and does not cover cloud provider availability or the uptime of your own application. It also does not cover application code, product design or data model problems; when that is the root cause we will say so rather than bill for the hours.
Billing and purchasing
How an engagement is quoted, bought and invoiced.
How much does it cost?
Engagements are fixed-fee and quoted per customer, so there is no price list on this site. What shapes the quote is which deployment tier you need, how many Blueprints you want deployed, and whether you add a Managed tier afterward.
How do I buy?
Two ways: directly, where we send an offer and, on acceptance, an invoice; or through an AWS Marketplace private offer, where you request the offer from the AWS account you want to pay from and accept it in the Marketplace console. The Marketplace path puts the purchase on your consolidated AWS bill, lets AWS discounts apply, and counts toward AWS spending commitments.
Does the fee include our cloud spend?
No. Cloud provider charges are billed to you directly by the provider and are separate from our fee, as are domain registration and your own application code. The platform is built with cost-aware defaults: cheap resilience is on, expensive features are off behind a switch whose comment states the price, so you can see what a control costs before you enable it.
Is a Managed tier required?
No. BuiltForProd Managed is optional and post-deployment, and a Baseline or Blueprint purchase hands over the repositories and the documentation whether or not you buy one. Many customers start with On-Demand hours and move to a Support SLA when a contractual obligation makes a response commitment necessary.
Technical
How the repositories behave once they are yours.
What tooling does it use?
The platform is built on open-source tooling: OpenTofu and Terragrunt for infrastructure, GitHub Actions with OIDC federation for pipelines, ArgoCD and Helm for the web application, SOPS with a cloud key service for secrets, and Checkov, Trivy and tflint for scanning. Every action is pinned to a commit hash and every module and provider to an exact version, and the pinned versions are published in the release notes.
Can we add an account, a stage or a region later?
Yes, and the address plan already reserves the space: in the AWS Enterprise Baseline, capacity for 16 regions and 8 workload stages per region. Adding an account is a map entry and a folder, adding a region is a folder whose name is the region, and the address manager, the region-restriction policy and the tag policy discover the new region themselves.
Do we have to use Kubernetes?
No. The foundation itself has no Kubernetes in it at all; the Web App Blueprint runs on a managed Kubernetes service because that workload suits it, and the Data and ETL Blueprint has no cluster. We are not a Kubernetes company, and the platform does not assume you are one.
How opinionated is it?
Deliberately opinionated, and legible about it. The repositories encode decisions such as one address plan, isolation between production and non-production, no long-lived keys, immutable image tags and a fixed promotion order. Every value that must be set for your organization is tagged in the code, and every optional choice is tagged with the trade-off and, where it costs money, the price.
Where to go next
- The support center routes any question that is not answered here.
- The knowledge base explains what documentation exists and how to reach it.
- The documentation FAQ answers the same questions in more technical detail, with the code behind each answer.
- Pricing explains what shapes a quote, and contact reaches a person.
Still have a question?
Ask it. If BuiltForProd is not the right fit for what you are trying to do, we will tell you that rather than sell you an engagement.