Approach

Discovery, build, run, grow

The same four stages whichever line you start with, and the same people accountable across them.

30 minutes with an engineer, no sales call

Why the stages exist

Most projects fail at the seams

When discovery gets skipped, the first estimate becomes the plan. Nobody has read the data model, nobody has asked what happens to the records that already exist, and the constraint that reshapes everything shows up in week five. The work then gets rebuilt at full price while both sides argue about whether it was in scope.

The opposite failure happens after launch. The build team leaves, the running system belongs to nobody in particular, and the first incident becomes an investigation into how the thing works. Alerts go unowned, credentials sit with whoever set them up, and the product stops changing because changing it feels dangerous. Keeping the same people accountable from build through run is the point of these four stages, not a service upsell.

The four stages

What each stage actually involves

Stage 01
Discovery
We read the system before proposing anything: the code, the pipeline, the data model, the incident history and the way decisions get made today. We agree what problem is being solved and what would count as done, and we write down the constraints that cannot move.
You get
A written read of the current state, a scoped plan with named risks, and the definition of done for the first increment. Yours to keep whoever builds it.
Our part takes
One to two weeks of our time, depending on how many systems are in scope
You provide
Read access to the repository, pipeline and logs, plus two working sessions with whoever knows the current system best
Stage 02
Build
We work in small increments behind review, each one shippable on its own. Decisions that change the shape of the system get written down when they are made. Risky changes ship behind a flag or in a window you choose, and anything that touches data arrives with a rollback path.
You get
Working software in your environment, reviewed and documented as it lands, with the decision record alongside it.
Our part takes
Increments of one to two weeks each, with a demo closing every one
You provide
One decision maker who can answer questions within a day, and access to the environments we are shipping into
Stage 03
Run
The same people who built it keep it alive. We set up monitoring on the paths that matter, agree a severity scale, and rehearse the incident procedure rather than writing it down and hoping. Routine work gets automated instead of remembered.
You get
Monitoring and alerting you can see, a written incident procedure that has been rehearsed at least once, and a named path when something breaks.
Our part takes
A rolling monthly arrangement you can end with notice
You provide
Ownership of the accounts and infrastructure, an agreed escalation contact, and a decision on what counts as an emergency
Stage 04
Grow
With the platform stable, we work on demand against it: search and answer engine visibility, measurement that respects consent, and structured tests on the pages that decide deals. Product changes and demand changes get measured against one source of truth instead of two.
You get
One measurement setup both sides trust, a prioritised list of tests, and the reasoning behind each change written down.
Our part takes
Monthly cycles, with the first cycle spent on measurement rather than spend
You provide
Access to analytics and ad accounts you continue to own, and someone who can approve copy and page changes

How we work day to day

Operating facts, not a philosophy

Decisions get written down: Anything that changes the shape of the system arrives as a short written note: the options, the tradeoff, the choice. You can read why something was built this way a year later without asking us.
One shared channel: We work in a single channel with you rather than splitting the thread across email, calls and private messages. If a decision happens on a call, it gets written into the channel the same day.
A demo closes every increment: At the end of each increment we show working software in your environment, not slides. If something did not land, we say what and why rather than reshaping the demo around it.
Every change gets reviewed: No change reaches your main branch without a second pair of eyes, including small ones and including ours under time pressure. Review comments stay in the pull request as part of the record.
Documentation is written as the work happens: Runbooks, architecture notes and setup steps are produced alongside the change, not gathered at the end. Documentation written after handover is documentation nobody trusts.
What we need from you to keep this pace: One person who can decide, answers to blocking questions within a working day, and access granted before the increment starts rather than during it. When those slip, the increment slips, and we will say so early.

Where we say no

Work we decline, and why

Fixed price on undefined scope

A fixed number against an undefined problem is priced for the worst case or delivered at the cheapest one. We scope discovery first, then fix the price of a defined increment.

Sole access to your accounts

You keep ownership of the cloud accounts, repositories, domains and ad accounts. We work inside them with our own credentials, and we never become the only party who can get in.

Guaranteed rankings or returns

Nobody controls a search engine's results or a market's response, so a guarantee on either is a sales tactic. We commit to the work and the measurement, and we report what happened.

Work with no named decision maker

If nobody on your side can approve a direction, the work stalls and both sides pay for it. We ask for one named person with the authority to decide before we start.

The first month

What a first month looks like

Week one

We get access, read the system and talk to whoever runs it now. Expect questions rather than proposals, and a written list of what we found unclear.

Week two

We agree the first increment and its definition of done, and we write down the constraints and risks we have found. You review that read and correct it before anything gets built.

Week three

Build starts in small reviewed changes. You see work in progress in the shared channel rather than waiting for a reveal at the end.

Week four

We demo what landed in your environment, hand over the notes and documentation produced along the way, and decide together whether there is a second increment.

Next step

Start with discovery on one system

Book a technical assessment