Skip to content

How we work: five phases, in order

The same sequence on every engagement, whatever the domain. Each phase produces something you can inspect, and ends on a decision you make — not on an invoice we send.

  1. Phase 1 of 5 — Assess

    What happens
    We read the estate as it is: the systems in place, the integrations holding them together, the regulation that applies, and the constraints nobody writes down. Interviews with the people who operate it daily, not only with those who sponsor it.
    What you get
    A current-state map, a prioritised gap list, and the risks ranked by what they would actually cost you — not by severity labels copied from a scanner.
    How it ends
    You decide whether the gaps we found are the ones worth closing. Some engagements should stop here, and saying so is part of the job.

  2. Phase 2 of 5 — Design

    What happens
    We architect the target state and write down the trade-offs — including the ones that went against our own commercial interest. Every significant decision gets a recorded rationale, so the next engineer inherits reasoning rather than archaeology.
    What you get
    A target architecture, a migration path in reversible stages, a technology selection with the alternatives and why they lost, and a cost model.
    How it ends
    You approve the architecture before anything is procured. A design you cannot challenge is a design you cannot own.

  3. Phase 3 of 5 — Implement

    What happens
    We build and migrate in stages small enough to roll back. Each stage has its own test, its own cutover window, and its own back-out plan written before it starts, not during the incident.
    What you get
    Working systems delivered incrementally, configuration under version control, and runbooks written as the work happens rather than reconstructed afterwards.
    How it ends
    Each stage is accepted on its own criteria. The engagement never depends on one irreversible weekend.

  4. Phase 4 of 5 — Enable

    What happens
    We hand over to your team: documentation, training against the real system, and time working alongside your engineers while we are still accountable. Handing over a set of credentials is not a handover.
    What you get
    Operational documentation, role-based training, and named people on your side who can run the system without calling us.
    How it ends
    Your team demonstrates the operations, not us. If they cannot, the enablement is not finished — regardless of what the plan said.

  5. Phase 5 of 5 — Operate

    What happens
    Where you want it, we run and improve the system under an agreed service level: monitoring, incident response, patching, capacity and periodic architecture review.
    What you get
    Defined service levels, reporting you can take to your board, and a review cadence where the architecture is revisited rather than frozen.
    How it ends
    It does not, until you end it — and when you do, we leave you able to run it. Exit is designed at the start, not negotiated at the end.

Continue reading