Approach

Engagements are shaped around the work rather than fitted to a template. What stays constant is how the work runs and the standard it has to meet before handover.

Engagement models

The shape of the work is agreed before it starts: how much time, which outcome and who is responsible for what.

Embedded delivery

An agreed number of days per week inside your team and your repository. This suits ongoing delivery alongside a team that already exists.

Fixed-scope build

A defined outcome, scoped and priced per project rather than by days alone. This suits a bounded build or migration with a clear end.

Advisory

Review and guidance days for a decision that is expensive to get wrong.

Cadence

The work follows the same four steps as how we work on the home page — Discover, Build, Prove, Hand over — and the cadence below keeps them visible rather than implied.

• Work in short increments, with something reviewable every week
• A standing channel with your team
• Decisions written down rather than remembered
• Updates that do not require a meeting
• A demonstration at the end of each increment
• Scope changes discussed before they land

Definition of done

Agreed before the build starts, not argued at the end. For most engagements it means:

• Acceptance criteria written down
• Tests covering the changed behaviour
• Performance and accessibility budgets met where the product has them
• A deploy that can be repeated
• Documentation and the runbook updated
• A walkthrough with your team

Handover

The engagement ends when your team can run the software without us.

• Repository and pipeline in your accounts
• Decision records in the repository
• A recorded handover walkthrough
• An agreed aftercare window for questions
• Nothing that locks you to us

To talk through which model fits the work, tell us what you are working on.