How we work
How an engagement runs
Most suppliers describe what they build. This page explains how your requirements are handled once the work starts: who sets the priorities, what you see along the way, and what you keep at the end.
The operating model
Four stages, each with something you keep
Each stage is described by what you get from it, rather than by what happens during it. An engagement can stop after any one of them.
Understand
We assess your systems, data, security and people. You receive a written view of where you really stand, which is often different from what the documentation says.
Discover · Assess
Decide
We produce a prioritised, costed plan that separates quick wins from larger structural work. You receive a plan you can present to your board, including what not to spend money on.
Advise · Prioritise
Deliver
We build to a production standard, put the system live and secure it and its access controls. You receive working software in small steps, and you can see progress throughout.
Build · Implement · Secure
Sustain
We provide support and monitoring, then help the system grow as the business changes. You receive agreed response times, and your own team is able to run the system.
Support · Grow
In practice
Not every engagement uses every stage, but the structure is always the same. That makes it easy to discuss scope and progress when something changes.
How we work with clients
Long-term partnerships, not one-off projects
This matters because of what the client gets: the same team that built the system stays with it, and one partner can extend the work into data, AI or security.
| We avoid | We work towards |
|---|---|
| One-off projects | Long-term technology partnerships |
| A single way of working together | Several ways to work together as needs change |
| Overcomplicated solutions | Simple, practical solutions |
| Delivering software in isolation | Complete digital transformation |
| One fixed starting point | Several ways to get started |
How a requirement is handled
From a request in a meeting to a change in production
Here is one requirement, followed from start to finish. Procurement teams usually ask about this, and most proposals leave it out.
- Raised
- The requirement is added to a single backlog with the name of the person who asked for it, so nothing is left in a conversation.
- Sized
- We estimate it as a range and list our assumptions. If the schedule is fixed, we also say what it would push back.
- Agreed
- You decide the priority. We do not reorder your backlog for you.
- Built and reviewed
- The work is written, tested and reviewed by another engineer, then demonstrated against the criteria agreed when it was sized.
- Released and recorded
- It is deployed through the automated pipeline, and the change is recorded against the original requirement.
Governance
What you receive, and how often
You receive regularly
- A new increment and a demonstration every two weeks
- A written progress update against the agreed scope
- An open log of risks and decisions
- A record of changes and their costs
- Uptime and environment reports once the system is live
- A quarterly review against the original business case
Good governance should be routine and easy to read. If a status report needs explaining, it is not doing its job.
See how this would work for you
Bring one real requirement, and we will show you how it would be sized, agreed, built and recorded.