Ship proven changes every week, safely.

Changes go out behind a flag with tests behind them, a rollback ready and a readout attached.

Start with a conversion review How it works

Every readout sets the next change

Sound familiar?

The fix is known and waits months behind platform work.
Every release breaks something nobody tested.
Nobody can tell a real failure from a flaky check.

A slow, risky release process caps what any test or fix can be worth, however good the idea.

What changes.

TodayWith the engine

Release rhythm: A batch every few weeksSmall changes every week, behind flags
Tests: Written after the bugDrafted with the change, run on every release
Failures: Hours spent separating real from flakyGrouped by cause, with the likely owner
Rollback: A hotfix under pressureA flag you switch off

How it works. 6 steps, 5 stages.

AI2
Rules and automation2
Your team2
Approval

1Accept
1. Your teamApproval
  Accept a change
  A decision from a diagnosis or a test, with its measure and its owner.
2Build
1. AI
  Draft the change and its tests
  Code, variants and tests drafted in your repository, for your engineers to review.
  - GitHub
3Test
1. Rules and automation
  Run the checks
  Build, unit tests and journey checks on key devices, with accessibility scans and a keyboard path.
  - Playwright
  - GitHub
2. Your teamApproval
  Review and approve
  An engineer checks correctness. A designer or category owner checks the experience.
4Release
1. Rules and automation
  Release behind a flag
  Exposure ramps up, guardrails on speed and errors watch, and one switch rolls it back.
  - GrowthBook
5Read
1. AI
  Draft the readout
  What changed, who saw it and what it did, with a decision and a date to check again.

Every readout sets the next change

What you get. Real work, every week.

ReleasesLast six weeks

Machine-washable answerFirst screen, from the spec · week 3LiveKept
Delivery date in the cartHalf the visitors · week 6OpenRunning
10% off a second jacketFlag off after two days−$4Rolled back

Every release and what became of it. A change that lost money is switched off in a day or two.

Release checks · week 6

39 of 40journey checks pass

Search finds CAT-042
Checkout completes on mobile
Keyboard path to payment
Product image loads in timeGrouped as flaky: timeout

The checks that run on every release. One failing check is grouped with its likely cause.

Release cardDelivery date in the cart

Half the visitors, one flag, ready to roll back.

Exposure: Half the visitors, persistent
Checks: Journey checks pass; one flaky check rerun
Guardrails: Page speed and support contacts
Rollback: One flag, no deploy
Read: After 10 weeks: a decision and a date

The release card an engineer signs before exposure ramps up.

How you’ll know it’s working.

Lead time from decision to live
Days from an accepted change to shoppers seeing it.
Defects that reach shoppers
Customer-impacting problems per release, with rollbacks counted.
Review and rework time
Drafted code that needs heavy rework moves the delay into review.

Baselines agreed before we build.

Works with what you have.

Delivery

GitHub
Playwright

Measurement

GrowthBook

Commerce

Shopify

We configure first: Your repository, your CI and a free flag tool carry most of this. We add what’s missing, not a new platform.
We build when: Known fixes wait on release capacity, or releases still break journeys nobody tested.

What a first build includes.

Built in your accounts, around your team. Scope, fee and baseline agreed before we start.

1Design
2Build
3Run it, or hand it over

Start with a review Scope this build

We build

A release pipeline with flags and guardrails
Journey checks on the paths that earn money
Drafted tests and grouped failures
A readout and a rollback for every change

We start from

Repository, CI and hosting access
Design system and theme code
Open fixes and test history

From your team

Owner: Head of ecommerce, with engineering
Involves: Engineering
Design
Ecommerce
QA

Questions teams ask.

Will you replace our developers or our agency?

No. We work in your repository with your engineers reviewing, and we leave the pipeline and the playbooks with you. If an agency owns the code today, we start by moving that know-how in.

Does AI-drafted code make this faster?

Sometimes. A 2025 randomized study by METR found experienced open-source developers took 19% longer with AI tools in that setting. So we judge accepted changes: the ones reviewed, tested and measured.

Who owns it once it’s running?

You do. It’s built in your accounts, documented, with training for the people who run it. Ownership usually sits with your head of ecommerce, with engineering. We can keep running it with you, or step back.

How do we start?

Usually with a conversion review: two to four weeks, a fixed fee credited to the build, and a plan that’s yours. If the job is already clear, we can scope the build directly.