Process
Evidence first,
then code.
Every engagement runs on the same eight stages. The order matters more than the labels: nothing is scoped before it is read, and nothing ships without a number attached.
- Stage 1
- Audit
- Typical scope
- Fixed
- Delivery
- Git + staging
- Handover
- Documented
The shape of an engagement
Eight stages, each with an artefact you can read.
No stage is complete because time passed. It is complete because something written exists — findings, an architecture note, a runbook, a report.
1# audit/day-one.sh2shopify theme pull --live3rg -c '{% section' templates/4npx lighthouse --preset=desktop --form-factor=mobile5 6# output: findings doc, not a sales deck- Audit
- Architecture
- Build
- QA
- Launch
01Stages
N1Small engagements compress stages into the same week. None of them get skipped.
- 01
Technical audit
Theme structure, app stack, script weight, data model, analytics and field performance data reviewed end to end. Output is a written findings document, not a call summary — you keep it whether or not the engagement continues.
- 02
Scope & estimate
The audit findings become a fixed-scope proposal or a retainer shape, priced against what we actually found rather than a guess. Anything ambiguous is flagged as a risk with an explicit contingency, not buried in the total.
- 03
Architecture
We agree the template architecture, the data model — native fields versus metafields versus an external system — and the render budget before any implementation code exists. This is the stage most agencies skip, and the one that determines whether the build is maintainable in a year.
- 04
Build in version control
Work happens in Git against a staging theme, shipped in small, reviewable slices. The live theme is never edited directly, and every change is traceable to a commit, an author and a reason.
- 05
QA against the budget
Cross-device QA, accessibility checks, and performance measured against the render budget agreed at the architecture stage. A regression fails the deploy rather than becoming next quarter's ticket.
- 06
Staged launch
Launches go out behind feature flags or to a percentage of traffic where the risk profile calls for it, with a tagged rollback point at every step. Nothing goes to 100% of traffic on a Friday afternoon without a reason.
- 07
Measure
Field data monitoring against the single metric agreed at scope stage — LCP, conversion rate, sync latency, whatever mattered for this engagement. We report what actually moved, including when it came in smaller than hoped.
- 08
Documented handover
Architecture notes, editor documentation and the explicit list of trade-offs we made, handed over in writing. Your team inherits the reasoning, not just the files, so the store stays maintainable without us.
02Tooling & environments
Boring, standard tools chosen so your next developer does not need a translation layer to understand the setup.
03Communication & reporting
You get a written update every week: what shipped, what is next, and what — if anything — is blocked. It goes out whether or not there is a scheduled call, because a status update should not depend on a meeting existing.
We use a shared board (Linear or Notion, your preference) that mirrors the Git history, so you can see the state of the work at 11pm on a Sunday without waiting for a reply. Calls are booked when there is a decision to make, not as a recurring ritual — most weeks that means one async update and no meeting at all.
For time-sensitive incidents — a broken checkout, a failed sync — we agree a response window up front as part of the engagement, typically same working day.
04What we need from you
- Admin (or collaborator) access to the store and the theme you want worked on.
- One named decision-maker who can approve scope changes without a committee.
- Access to any third-party systems in scope — ERP, PIM, CRM — with a technical contact if one exists.
- Honesty about hard constraints: a launch date, a peak trading window, a budget ceiling.
That is the whole list. We do not need daily stand-ups, a dedicated Slack channel per feature, or sign-off on every commit.
05Risk handling & rollback
Every deploy is tagged, so reverting to the last known-good state is a single command, not a scramble. If a launch shows a regression in production, we roll back first and diagnose the root cause afterwards on staging — the priority order is always stability, then curiosity.
High-risk changes — a checkout rewrite, a data migration, a new integration touching live orders — are staged behind a flag or to a percentage of traffic first. We would rather find a problem affecting 5% of sessions than 100% of them.
For migrations specifically, the legacy system stays untouched and readable until the new one has proven itself against real orders for an agreed window, so there is always a way back.
06Working agreement
- One senior engineer owns your project from audit to handover.
- Weekly written update: what shipped, what is next, what is blocked.
- Live theme is never edited directly — all work is reviewable in Git.
- Scope changes are re-quoted in writing before they are built.
- You own the repository, the documentation and the accounts. Always.
07Questions
Process
Start where we always start.
A technical audit of your store. You get the findings document whether or not you go on to work with us.