Skip to content
AMPHOZE

Approach

A method that ends in decisions, not deliverables.

Consulting fails in predictable ways: the diagnosis is an opinion, the design is a slide, and the client cannot tell whether the result was worth the money. We work in seven steps, each producing something concrete and each ending at a point where you can continue, redirect or stop with the evidence in front of you.

The sequence

Seven steps, in this order, for a reason

Each step consumes what the previous one produced. Skipping a step does not save time; it moves the cost to integration, where it is highest.

Fig. 01 — Engagement sequence
  1. 01

    Understand

    We spend time with the people who do the work, not only the people who commission it. We read the code, watch the process run, and find out which parts of the system everyone quietly works around.

  2. 02

    Diagnose

    We instrument before we opine. Traces, query plans, queue depths, error budgets, handling time per manual step, cost per transaction — whatever the specific system makes observable.

  3. 03

    Design

    We put up two or three architectures that would each work, and argue them against the constraints from step 01 and the numbers from step 02. Failure modes, migration paths and operational load are part of the comparison, not an afterthought.

  4. 04

    Build

    We build in increments that each reach a usable state. Code lands in your repository, on your CI, reviewed by your engineers, from the first week rather than at handover.

  5. 05

    Integrate

    Real authentication, real data volumes, real upstream systems and their real failure behaviour. This is where most estimates break, so we get here early rather than last.

  6. 06

    Measure

    We re-run the step-02 instrumentation against the changed system. Same method, same definitions, so the comparison means something.

  7. 07

    Improve

    We close the loop: the instrumentation stays on, the known trade-offs go on a backlog rather than into folklore, and your engineers take the system over with us still reachable.

The loop closes: step 07 feeds the next iteration of step 01. Engagements that end at step 04 leave working software with no evidence that it helped.

Artefacts and decisions

What each step leaves behind

An artefact is something that outlives the meeting it was made in. A decision is a choice you own, made with that artefact in hand.

  1. 01Understand

    We produce
    A written problem statement: the systems in scope, the constraints we are not allowed to break, the people affected, and the things we were told that turned out not to be true.
    You decide
    Whether the problem we wrote down is the problem worth spending money on. Reframing here is cheap; reframing after a build is not.

  2. 02Diagnose

    We produce
    A measured baseline, recorded before anything changes, with the method written down so the same numbers can be produced again later by someone else.
    You decide
    Which of the measured problems get funded. A baseline usually shows that the loudest complaint is not the largest cost.

  3. 03Design

    We produce
    A written architecture decision record for each significant choice: options considered, the option taken, the trade-off accepted, and the evidence that would make us reverse it.
    You decide
    Which architecture gets built — and, explicitly, which downsides you are choosing to live with. There is no option without a downside; we will name it.

  4. 04Build

    We produce
    Working software with tests, migrations, structured logging and a runbook — not a prototype that has to be rewritten before it can be trusted.
    You decide
    After each increment: continue, change direction, or stop. Stopping early with a working subset is a legitimate outcome, and the increments are sized so it stays available.

  5. 05Integrate

    We produce
    The system running against production data paths behind a controlled rollout, with rollback documented and actually rehearsed at least once.
    You decide
    When it goes live, for whom, and at what blast radius. You choose the exposure; we make each level of exposure technically available.

  6. 06Measure

    We produce
    A before-and-after on the metrics we agreed mattered, including the ones that moved the wrong way. Regressions are reported, not filtered.
    You decide
    Whether the change earned what it cost, and whether the next increment is still worth funding on the evidence rather than on momentum.

  7. 07Improve

    We produce
    A handover pack: ownership map, on-call path, the decision records, the open trade-offs, and the next measurable improvement with its expected cost.
    You decide
    Whether the work continues with us, continues with your team, or ends here. A clean exit is part of the deliverable, not a negotiation.

Engagement shapes

How the work is actually structured

Three shapes cover almost everything we do. The differences that matter are where the engagement starts, who owns the direction, and what happens when the estimate is wrong.

Discovery sprint

A short, fixed-scope engagement that runs steps 01 to 03. It ends with a written diagnosis, a measured baseline, and costed architecture options.

Suited to — A problem that is felt clearly but described vaguely, or a build that has been proposed internally and needs an outside opinion before it is funded.

Honestly — A discovery sprint can conclude that you should not build the thing. That is a real possible outcome and we will write it down plainly rather than manufacture a project out of it.

Build engagement

Steps 03 to 06 against a defined outcome, delivered as increments that each go to a usable state. Scope, not hours, is the unit of agreement.

Suited to — A decided direction that needs engineering capacity and architectural discipline applied to it end to end.

Honestly — Estimates are ranges with the assumptions attached, and integration is where ranges widen. We will not quote a delivery date we cannot defend, and we will tell you when a scope change has moved the range.

Embedded team

Our engineers work inside your team — your repositories, your review process, your standups, your definition of done. We adapt to your process rather than importing ours.

Suited to — Sustained work where the context lives in your organisation and pulling it out to a separate team would cost more than it saves.

Honestly — This only works when there is a technical owner on your side who can make calls. Without one it degrades into staff augmentation, where nobody is accountable for the architecture and everybody is busy.

We do not publish standard durations. Two engagements with the same description differ by an order of magnitude depending on the state of the existing system, and a number invented before we have seen it would be marketing rather than an estimate.

Collaboration

We work with your engineers, not around them

The team that will run this system for the next five years is already in your building. Anything that routes around them is a short-term convenience with a long-term bill.

Your repository, from day one

Work happens in your version control, your CI and your environments. There is no separate codebase that appears fully formed at the end, because that is how knowledge gets stranded on our side of the contract.

Review runs both ways

Your engineers review our pull requests and we review theirs. It is slower in week one and considerably faster by week four, because it surfaces disagreements about the design while they are still cheap.

Decisions get written down

Every consequential choice becomes a short decision record in your repository. When someone asks in eighteen months why the queue is where it is, the answer exists in writing and does not depend on us being reachable.

We pair instead of handing over

Handover is not an event at the end. Ownership transfers continuously by working together on the code, so by the time the engagement closes your team has already been running the system.

We defer to your constraints

If your platform team has standardised on a stack, an approval process or a deployment model, that is a constraint we design inside. We will argue the technical case once, in writing, and then we implement the decision that was made.

We leave the operational path behind

Runbooks, dashboards, alert thresholds and the failure modes we know about. A system your team cannot operate on a bad night is not finished, regardless of what the tests say.

Start at step 01

Tell us what is not working. We will start by writing it down.

The first conversation is a diagnosis, not a pitch. Bring the system, the constraints and the thing everyone works around.

Start a ConversationSee what we work on