How we work
Five phases. Stop after any of them.
Each phase is separately scoped, separately priced and terminable at two weeks' notice, with everything produced to that point staying yours. Two clients have used that in six years and both left on good terms.
- 012 weeks
Diagnose
Analytics audit, session review, customer interviews and a merchandising teardown. We finish with a written diagnosis of what we think is costing you money, and it is yours whether or not you hire us for the rest.
The diagnosis document is yours whether or not you go further with us. Several clients have taken it in-house and executed it themselves, which we consider a perfectly good outcome.
You end up with
- Written diagnosis
- Prioritised opportunity list
- Sized commercial case
- 023 – 5 weeks
Design
Information architecture, then a design system built inside real product layouts. Nothing is signed off as a static frame — you approve it in a working prototype with your own catalogue in it.
You end up with
- IA and flows
- Design system in Figma
- Clickable prototype
- 036 – 10 weeks
Build
Two-week sprints in your repository, with a demo environment updated on every merge. Your engineers are on the pull requests from sprint one — this is not a black box that opens at the end.
You end up with
- Storefront in your repo
- Test suite and CI
- Staging on every branch
- 041 – 3 weeks
Launch
Staged cutover with a tested rollback at every stage, a monitored launch window and a war-room channel that stays open for a fortnight. We test a rollback every time regardless of how confident we are.
Launch windows are agreed with your team, never imposed. We do not launch on a Friday, before a bank holiday, or in your peak trading fortnight — three rules that have each been learned the hard way, though not by us.
You end up with
- Cutover runbook
- Rollback plan
- 30 days of monitoring
- 05Ongoing
Compound
A launch is a starting position, not a result. The retained programme runs experiments, reports on cohorts and keeps the thing getting better after everyone has stopped paying attention to it.
You end up with
- Monthly experiments
- Quarterly readout
- Cohort reporting
Principles
Six rules we do not bend
Each of these has cost us at least one project. We have kept them anyway, which is the only real test of whether a principle is one.
Diagnose before you prescribe
We will not quote a build until we have looked at your analytics, watched twenty sessions and spoken to five of your customers. Anyone who quotes a redesign off a screenshot is selling you a shape, not a solution.
Fixed price, fixed scope, written down
Time and materials makes the agency the only party who benefits from slippage. We price phases fixed, in enough detail to be argued about, and changes go through a written change order with a number on it.
Ship in your repository
Not ours, not a staging sandbox we hand over at the end. Your organisation, your CI, your engineers on the pull requests from sprint one.
Demo on every merge
A deploy preview for every branch and a working demo environment updated continuously. You should never be waiting for a Friday show-and-tell to find out what we built.
Test the rollback every time
We have never had to use one in six years and we build one for every launch anyway. The rollback is not for the likely case, it is for the case that ends your quarter.
Leave the team better than you found it
Every engagement includes knowledge transfer as a deliverable rather than a courtesy. If your team cannot maintain it after we leave, we have failed regardless of what the metrics say.
Working together
What we need from you
Projects fail on availability far more often than on ability. Three things, and we will say so early if they are not happening.
- 01
One decision-maker
Someone who can say yes without convening a committee. Design by consensus produces work nobody objects to and nobody wanted.
- 02
Two hours a week
A standing session with the same people. Not a status update — a working session where decisions actually get made.
- 03
Access on day one
Analytics, repository, staging, the ERP if there is one. Every week of access negotiation is a week of the project spent on nothing.
Questions
Before you ask
The people you meet in the pitch. We run a small number of projects at a time and there is no delivery team you have not been introduced to. If we are too busy to staff you properly we will say so and give you a date.
Entirely, from the first commit, in your repository under your organisation. There is no proprietary framework, no licence, and nothing that stops you taking it in-house or to another agency tomorrow.
Shopify and Shopify Plus most often, plus Commerce Layer, Medusa, BigCommerce and bespoke APIs. The storefront is almost always Next.js. If you tell us your requirements point at a platform we do not work with, we will tell you that rather than bend the project towards us.
Preferably. The best projects we run have client engineers on the pull requests from sprint one. We are equally happy being the whole team, but we will always push for knowledge transfer rather than dependency.
Fixed price against a fixed scope, in phases, with the scope written down in enough detail to be argued about. Changes go through a written change order with a price on it. We do not do time and materials because it makes us the only party who benefits from things taking longer.
Phases are separately terminable with two weeks’ notice, and you keep everything produced up to that point. Nothing is locked to us.
Occasionally, for early-stage brands where it makes more sense than a cash fee. Ask us.
Ask us — availability changes. If you need something faster than we can commit to, we will tell you rather than string it out.