Skip to main content
FreeAWS Well-Architected Review twice a year when you pay AWS through usSee Cloud Billing (opens in a new tab)

Cloud Build & Launch: Your software, live on a cloud you own

We plan, build and launch the cloud for your software, in your accounts, as code. You sign off every step.

Plan a build (opens in a new tab)See what you hold at launch

What you hold on launch day

Your cloud account

Owner: you

  • Production
  • Staging
  • Test

Four moves, each ending in your yes

  1. Plan and design

    We turn your brief into a plan and a design you can read.

    You receiveThe plan and the design

    You sign the plan and the design

  2. Build in sprints

    The foundation first, then your application’s cloud, sprint by sprint.

    You receiveA working increment each sprint

    You accept each sprint

  3. Test and launch

    You test it. We go live, with a way back.

    You receiveTest results and the runbook

    You sign off UAT and go-live

  4. Stay close

    The build team stays on after launch, then hands over.

    You receiveA hypercare report and a tuned runbook

    You close hypercare
Managed ServicesAfter hypercare (opens in a new tab)

Plan

Brief to backlog

What happens

  • We turn your brief into a backlog, each story with tests you can run.
  • We agree what done means: goals, limits and who decides.

Who does what

You
Bring the brief, the users and the priorities.
Architects
Scope the cloud side and name the risks.
Engineers
Size the backlog and flag what is unclear.
AI assistant
Drafts the stories. A person edits every one.

Rituals

  • Kick-off
  • Backlog refinement

You receive

  • The scope and the backlog
  • A plan with dates
  • A monthly run-cost model at three levels of use

Exit gate

You approve the plan, and the build is quoted from it.

Design

Architecture and system design

What happens

  • We gather your inputs: users, load, data, recovery needs and rules.
  • We draw two or three options and record the choice and the reason.

Who does what

You
Answer the design questions and choose.
Architects
A certified cloud solution architect leads the design and signs it off.
Engineers
Try the risky parts in a short spike.
AI assistant
Drafts diagrams and the threat model for the architect to correct.

Rituals

  • Design workshop
  • Design review

You receive

  • Architecture and data-flow diagrams
  • Decision records
  • The security design and the failure review
  • The cost model, refined

Exit gate

The design review is signed by the architect and by you.

Foundation

Sprint zero

What happens

  • Accounts in your name, sign-in, network and logging, all as code in your repository.
  • Development, staging and production from one template.

Who does what

You
Create the accounts and give developers access.
Architects
Check the foundation against the design.
Engineers
Write the code, and open every change as a pull request.
AI assistant
Drafts the infrastructure code and tests.

Rituals

  • Sprint planning
  • Daily check-in
  • Sprint review

You receive

  • The foundation, running in your accounts
  • A pipeline that deploys on merge
  • The first runbook pages

Exit gate

A merge reaches staging by itself, and you have seen it.

Build

Sprint by sprint

What happens

  • Each sprint takes the top of the backlog and ends with something working in staging.
  • Your developers deploy from the first sprint.

Who does what

You
Order the backlog, and accept or reject each story.
Architects
Review changes that touch the design.
Engineers
Build, test and demo a working increment each sprint.
AI assistant
Drafts code and tests, through reviewed pull requests.

Rituals

  • Sprint planning
  • Daily check-in
  • Sprint review and demo
  • Retrospective
  • Backlog refinement

You receive

  • A working increment after every sprint
  • A burn-up of what is done and what is left
  • Runbook pages for each new service

Exit gate

At each sprint review, you accept the stories that meet the definition of done.

UAT

You test it

What happens

  • We run the acceptance scenarios on a staging environment that matches production.
  • You test it the way real users will, and log what you find.

Who does what

You
Run the scenarios, and sign off what passes.
Architects
Judge the load and restore results.
Engineers
Fix defects by severity, and retest.
AI assistant
Drafts test cases and sums up the results.

Rituals

  • Test kick-off
  • Daily defect review
  • Sign-off meeting

You receive

  • The UAT report
  • Load, restore and security results
  • The Well-Architected review report

Exit gate

You sign off UAT. Nothing goes live without it.

Launch

Go-live, with a way back

What happens

  • We write the go-live plan, including the point of no return.
  • We rehearse the launch and the rollback on staging.

Who does what

You
Agree the date, and make the go or no-go call.
Architects
Confirm production matches the signed design.
Engineers
Run the cutover, and the rollback if needed.
AI assistant
Watches the alarms and groups related alerts.

Rituals

  • Go-live rehearsal
  • Go or no-go meeting
  • Launch call

You receive

  • Production, live
  • The final runbook
  • The rollback plan, rehearsed

Exit gate

The go or no-go meeting, and then the launch call.

Hypercare

The build team stays close

What happens

  • For a period agreed in the plan, the build team watches it and fixes what real traffic shows.
  • We tune alarms, capacity and cost, and close open items.

Who does what

You
Report what users see.
Architects
Compare real load with the design.
Engineers
Fix, tune and update the runbook.
AI assistant
Watches the system and drafts the daily summary.

Rituals

  • Daily check-in, then less often
  • Hypercare review

You receive

  • A hypercare report
  • Tuned alarms and capacity
  • A runbook updated from real incidents

Exit gate

Hypercare ends when the measures agreed in the plan have held for the time agreed in the plan.

The AI assistant drafts and checks. A named engineer reviews every output, and it never changes your accounts on its own.

A design checked before anything is built

A man explaining a plan at a chalkboard wall to colleagues at a table
  1. Operational excellenceCan it be changed safely?
  2. SecurityWho can do what?
  3. ReliabilityWhat fails, and then?
  4. Performance efficiencyIs it fast as use grows?
  5. Cost optimizationWhat does each month cost?
  6. SustainabilityDoes it use only what it needs?
  • A certified cloud solution architect signs it
  • The risky part is tried first
  • Checked again before launch
See what we ask, and what the architects produce

What we ask you

  • Who uses it, now and later
  • How much data, and how fast it grows
  • How long you can be down
  • Rules that apply: payments, health, privacy
  • What it may cost each month

What the architects produce

  • Context and data-flow diagrams
  • Account, network and access design
  • The security design and a threat model
  • A failure review
  • The cost model at three levels of use
  • Decision records

How it is checked

  • A certified cloud solution architect leads and signs the design
  • Checked against the six pillars below
  • The risky part is tried first
  • A Well-Architected review before launch, on the cloud you chose

Right-sized for where your product is

How far each layer goes now: decided, basic, solid, full.

Not built yet, on purpose
  • Kubernetes, unless your team already runs it.
  • A second region. Nobody has users there yet.
Not built yet, on purpose
  • A second region. One region across zones is enough to launch.
  • Custom dashboards. The defaults show what matters first.
  • A service mesh. Too few services to need one.
Not built yet, on purpose
  • Two live regions. A tested recovery plan comes first.
  • Rebuilding what works.
Not built yet, on purpose
  • Rebuilding for its own sake.
Scope your build (opens in a new tab)

After hypercare, our managed service can take over

When hypercare ends, our managed service starts from the runbook, or your own team takes over with everything in hand.

See managed services (opens in a new tab)

Built and launched for these teams

All case studies (opens in a new tab)

Questions before you plan a build

How long does a build take, and what does it cost?

It depends on the environments and services you need. The plan comes first, with dates and the monthly cloud bill, and the build is quoted from it.

Do you run Kubernetes?

Only when your team already runs it, or the workload needs it. Until then, a runtime the cloud runs for you is simpler to keep.

Which cloud do you build on?

The one that fits your product and team: AWS, Azure or Google Cloud. The base is the same on each, written as code from that cloud’s own services.

Do you write the application too?

Your developers write it, and we build the cloud it runs on. Brain Station 23’s software teams can build the application too, planned together.

What does the AI assistant do, and what does it not?

It drafts stories, diagrams, code, tests and runbook pages. A named engineer reviews every output, and it never changes your accounts on its own.

The engineering behind it

What usually comes next

Tell us what you run and need next

Talk to an engineer (opens in a new tab)See our work (opens in a new tab)
  1. You writeWith the form, or to [email protected]
  2. An engineer repliesWithin one business day, from the team that would do the work
  3. You get a scope and a priceIn writing, before any work starts