Skip to content
FiveX

Five steps.
Nothing hidden between them.

How a FIVEX engagement actually runs, week by week, including what happens when the scope moves.

The five steps

Every step ends in something
you can open and read.

  1. Discover

    1–2 weeks

    We map the system, the constraints and where the risk actually sits.

    Nothing is estimated before the unknowns are written down.

    You receive

    • Scope document
    • Estimate
    • Risk list

    We need from you: Access to the people who know the current system, and any documentation that exists.

  2. Design

    2–3 weeks

    Flows, interface and the data contracts, before production code.

    You approve a clickable prototype rather than a description.

    You receive

    • Clickable prototype
    • Component library
    • Data contracts

    We need from you: One decision-maker who can approve the flows within a week.

  3. Build

    [N]–[N] weeks

    Two-week iterations. A demo at the end of each, from the real system.

    Scope moves between iterations, never inside one.

    You receive

    • Working increment
    • Source access
    • Demo recording

    We need from you: Attendance at the fortnightly demo, and answers on open questions inside two working days.

  4. Deploy

    1–2 weeks

    Staged rollout with monitoring and alert thresholds agreed in advance.

    We rehearse the cutover, including the rollback.

    You receive

    • Runbook
    • Monitoring dashboard
    • Handover session

    We need from you: A maintenance window, and a named contact on your side for the cutover.

  5. Support

    Ongoing

    A named engineer with your system in their head.

    Fixes, updates and capacity planning, inside an agreed response window.

    You receive

    • Response window
    • Monthly report
    • Capacity plan

    We need from you: A single channel for requests so nothing arrives only in someone’s inbox.

What a build week looks like

One planning call, one demo,
and no status meetings.

  • Monday

    Planning

    We agree what ships this iteration and what is at risk.

    30 minutes, notes in the board.

  • Tuesday–Thursday

    Build

    Working sessions on request. No status meetings.

    Questions answered same day.

  • Friday

    Demo

    A running system, not slides.

    Recording and a written summary by end of day.

When scope changes

Scope will change.
Here is exactly what happens.

  1. 01

    A change is raised

    Anyone can raise one, in the board or on the weekly call. It gets written down the same day.

  2. 02

    It is re-estimated

    We price the change in days and say what it displaces. No change is absorbed silently.

  3. 03

    You decide the date

    Either the scope moves out, the date moves, or the change waits. You pick, in writing.

Where the work lives

  • The repository

    Your organisation on [repository host], with our commits in it from day one.

  • The board

    [board tool], one card per unit of work, visible to you without asking.

  • The weekly call

    One scheduled call, [N] minutes, with the engineers on the work.

  • The written summary

    Every Friday: what shipped, what did not, what changed.

Tell us what you need to build.

Send the constraints, the deadline and the hardware. We reply within [N] working days.