1. Home
  2. Process
Our process

Six stages, and you always know which one you are in

The same sequence runs through every engagement, whether it is a four-week assessment or a two-year platform build. Stage names appear on your invoices and status reports so progress is never ambiguous.

01

Discovery

We interview your stakeholders, read the existing code and infrastructure, and map constraints — budget, compliance, team capacity and immovable deadlines. Nothing is proposed until we understand what we are walking into.

  • Stakeholder interviews
  • Codebase and infrastructure review
  • Constraint and risk register
3–10 days
02

Blueprint

A written plan with architecture diagrams, milestone breakdown, named team, identified risks and a costed schedule. You can take this document to another vendor — it is yours either way.

  • Solution architecture
  • Milestone and cost plan
  • Named delivery team
1–2 weeks
03

Build

Two-week sprints, each ending in a working demo on a real environment. You have repository access, board access and a written status note every Friday.

  • Sprint demos every 2 weeks
  • Weekly written status
  • Continuous integration from sprint one
Ongoing
04

Assure

Automated regression, performance testing under expected peak, security review and accessibility checks. Defects are triaged with you, not silently deferred to a later release.

  • Automated test suites
  • Performance and load testing
  • Security and accessibility review
Parallel to build
05

Enable

Before handover, we train the people who will own the system. Runbooks, architecture decision records and recorded walkthroughs are deliverables, not afterthoughts.

  • Runbooks and ADRs
  • Team training sessions
  • Recorded handover walkthroughs
1–3 weeks
06

Sustain

Hypercare for the first weeks after go-live, then either a managed support agreement or a clean exit. Both are fine outcomes — we would rather leave than be needed unnecessarily.

  • Hypercare support window
  • Monthly service reviews
  • Optional managed support
30 days+
Working with us

What we need from your side

Engagements slow down for predictable reasons. Getting these four things right at the start prevents most of them.

  • One decision-maker. Someone empowered to approve scope changes without a committee.
  • Access on day one. Repositories, environments and the people who know the history.
  • Two hours a week. A standing slot for demo and decisions. Missed sessions are the single biggest cause of slippage.
  • Honest constraints. Tell us about the budget ceiling and the political landmines early. We plan around them better than we recover from them.

Reporting rhythm

Written status every Friday. Demo every second Friday. Monthly steering review with commercial and risk summary.

Tooling

We work in your stack — Jira, Azure DevOps, Linear, GitHub, GitLab. We do not require you to adopt ours.

Escalation

A named account lead outside the delivery team, reachable directly, who owns anything the pod cannot resolve within 48 hours.

Adaptations

How the six stages flex by service

The sequence holds. What changes is the weight of each stage.

Training engagements

Discovery becomes a skills assessment of the cohort. Build becomes curriculum development, reviewed by your principal engineers before the first session.

Advisory engagements

Discovery and blueprint carry the entire engagement. There is no build stage — the deliverable is the decision document and the working session around it.

Placement engagements

Discovery is a role calibration with the hiring manager. Assure becomes the technical screening standard, and Sustain becomes the 90-day assurance window.

Stage one is a conversation

Discovery calls are free and carry no obligation. Bring the problem, and we will tell you what the first two weeks would look like.