Engagement models
The right structure depends on the decision in front of you: continuous capacity against a roadmap, a defined system delivered end to end, or an assessment that decides what is worth building at all.
Models
A dedicated team working continuously against your roadmap, with predictable monthly capacity and a standing review rhythm.
Best when: You have a system in production, or a roadmap that keeps producing work, and you want continuity rather than a series of projects.
A defined system scoped, designed, built and delivered against agreed milestones and acceptance criteria.
Best when: The problem is well enough understood to define an outcome, and you need a specific system delivered and handed over.
Project-based or term engagements to assess readiness, identify opportunities and prioritise what is worth building.
Best when: You need a decision before a build: what to do first, what it is worth and whether custom software is even the right answer.
Compare
Most engagements begin with a consulting or proposal stage and move into a build or retainer once the first outcome is clear.
| Model | Commercial shape | Scope | What you receive |
|---|---|---|---|
| Retainer development team | Monthly capacity, ongoing term | Rolling roadmap, re-prioritised regularly | Continuous releases and a team that keeps context |
| End-to-end build | Milestone-based against a defined outcome | Fixed at proposal, changes handled explicitly | A delivered system with migration, training and handover |
| AI strategy consulting | Project or term engagement | Assessment and prioritisation, not implementation | A readiness view, prioritised roadmap and recommendation |
Included in every engagement
The people who scope the engagement are the people who build it. No layers between you and the system.
Working increments, a standing review rhythm and direct access to the team, not status percentages.
Each milestone defines what finished means before the work begins, so sign-off is not a negotiation.
Record ownership, roles, auditability and error handling are part of the build, not a later phase.
Delivery includes getting the operation onto the system, not just shipping the code.
Support and continued improvement are agreed at delivery rather than left open.
Pricing
Describe the workflow and the decision you are trying to make. We will tell you which structure suits it, and whether a build is warranted at all.