Process

Five steps, and permission to stop at any of them.

Nothing here is unusual. What matters is that each step ends with something you can read, use, or reject — so you are never asked to trust invisible progress.

  1. 01

    Frame the problem

    Days, not weeks

    Before scoping anything we establish what would have to be true for this project to be worth doing, and what would make it a mistake.

    • A short engagement — usually a handful of conversations and a look at the systems involved.
    • Output is a written problem statement, the constraints that matter, and an honest note on anything we think is the wrong idea.
    • If the answer is that you should not build this, we will say so here, while it is still cheap.
  2. 02

    Shape the work

    One to two weeks

    We define the smallest version that delivers the outcome, and draw a boundary around it that both sides can hold.

    • Architecture decisions get written down with their trade-offs, not just their conclusions.
    • Scope is fixed by outcome and time, with an explicit list of what is deliberately excluded.
    • You get an estimate with its assumptions attached, so you can see which ones move the number.
  3. 03

    Build in increments

    Continuous

    Work lands in slices you can use. Every increment is deployed, tested, and reviewable — there is no phase where progress is invisible.

    • Weekly demos against the real system, not slides.
    • Tests and CI from the first commit; deployment is not a phase at the end.
    • Scope changes are welcome and costed openly rather than absorbed quietly.
  4. 04

    Harden and hand over

    Before launch, not after

    Performance, accessibility, observability and documentation are part of the build, not a follow-up project.

    • Load and failure testing against realistic conditions.
    • Runbooks, architecture notes and an onboarding path for whoever maintains it next.
    • Handover is a working session, not a document dump.
  5. 05

    Stay useful

    As long as it earns its place

    Ongoing support sized to what you actually need — and an explicit invitation to end it when you do not.

    • Monitoring and on-call arrangements matched to the system’s real criticality.
    • A regular review of whether the retainer is still worth its cost.
    • Everything you need to take the work in-house, whenever you want to.

Working together

Start with step one.

Framing the problem is a short, low-commitment engagement. It ends with a written problem statement you own — whether or not you continue with us.

Get in touch