Engagement model

How we work

Six steps, run in the same order on every engagement and scaled to the size of the project. You always know which step you are in, and what it produces.

01

Discover

Understand the problem before proposing anything.

We start with the business problem, not the technology. That means sitting with the people who live with the current system, walking the environment as it really is, and writing down the constraints — budget, timing, compliance, the third-party system nobody is allowed to touch.

What happens

  • Stakeholder interviews
  • Environment and dependency review
  • Constraint and risk capture
  • Success criteria agreed in writing

What you receive

  • Current-state summary
  • Agreed scope and success criteria

02

Design

Decide the approach, and write down why.

Architecture, implementation approach, security considerations and technical requirements are documented before work starts. Where there is a real trade-off, you see both options and the reasoning — not just the one we happened to prefer.

What happens

  • Target architecture
  • Security and access design
  • Implementation and sequencing plan
  • Technical requirements

What you receive

  • Architecture diagram
  • Implementation plan
  • Design decisions

03

Build

Implement the approved solution.

Implementation follows the approved design. Changes that come up mid-build get raised, priced and agreed rather than absorbed quietly — scope creep is how projects stop finishing.

What happens

  • Implementation and configuration
  • Development where custom work is in scope
  • Progress checkpoints
  • Change control on anything outside the agreed scope

What you receive

  • The implemented solution
  • Configuration record

04

Validate

Prove it works before anyone depends on it.

Testing against the acceptance criteria agreed in Discover. Failure modes get exercised deliberately, not discovered in production at 2am.

What happens

  • Functional testing against acceptance criteria
  • Failure and recovery testing where relevant
  • Issue resolution
  • Production-readiness review

What you receive

  • Test results
  • Sign-off against acceptance criteria

05

Document

Leave behind something a stranger could operate.

Documentation is a deliverable, not a favour. Architecture diagrams, configuration detail, operating procedures and runbooks are produced as part of the engagement and handed over in a form you own.

What happens

  • As-built architecture diagrams
  • Configuration and environment documentation
  • Operating procedures and runbooks
  • Known limitations written down honestly

What you receive

  • Documentation set
  • Diagrams
  • Runbooks

06

Handoff

Transfer the knowledge, then close the project.

A working session with the people who will own the system, a walkthrough of the documentation, and a formal closeout. You should not need us to keep the lights on.

What happens

  • Knowledge transfer session
  • Documentation walkthrough
  • Outstanding items and recommendations
  • Project closeout

What you receive

  • Handover session
  • Closeout summary

After handoff

What happens when the project ends

After handoff, continued involvement is arranged separately — a scheduled advisory arrangement, a follow-on project, or a block of consulting time. It is a deliberate decision on both sides rather than an open-ended support obligation attached to the original project.

  • Scheduled advisory time, booked in advance
  • A follow-on project with its own scope
  • A block of consulting hours drawn down as needed

Ready to start at step one?

Discovery is where every engagement begins. Tell us what you are trying to achieve and we will take it from there.