How we work
How an engagement runs
Most suppliers describe what they build. This page describes how your requirements are handled once work starts: who decides priority, what you see, and what you keep at the end.
The operating model
Four stages, each producing something you keep
The stages describe what you get out of each phase rather than what happens inside it. An engagement can stop at any one of them.
Understand
Discovery and current-state assessment across systems, data, security and people. You get a written view of where you actually stand, which is often not where the documentation says.
Discover · Assess
Decide
A prioritised, costed path, quick wins separated from structural work. You get a plan you can put in front of a board, and a statement of what not to spend on.
Advise · Prioritise
Deliver
Built to a production standard, implemented live, with the system and its access model secured. You get working software in short increments, visible throughout.
Build · Implement · Secure
Sustain
Support and monitoring, then scaling as the business changes. You get agreed response commitments and a team of your own that can run the system.
Support · Grow
In practice
Not every engagement uses every stage, but the shape is consistent. That is what makes scope and progress simple to discuss when something changes.
How we work with clients
Long-term partnerships, not isolated deliveries
The distinction changes what a client gets: continuity of the team that built the system, and one partner who can extend into data, AI or security.
| We avoid | We build towards |
|---|---|
| One-off projects | Long-term technology partnerships |
| A single revenue relationship | Multiple ways to engage as needs evolve |
| Complex product thinking | Simple, practical solutions |
| Software delivery in isolation | End-to-end digital transformation |
| A single entry point | Multiple client entry points |
How a requirement travels
From a request in a meeting to a line in production
One requirement, followed end to end. This is the part that procurement usually asks about and that most proposals leave out.
- Raised
- Captured in one backlog with a named requester, so nothing lives only in a conversation.
- Sized
- An estimate as a range, assumptions listed, plus what it displaces if the schedule is fixed.
- Agreed
- You decide priority. We do not reorder your backlog on your behalf.
- Built and reviewed
- Written, tested, peer reviewed, and demonstrated against the criteria agreed when it was sized.
- Released and recorded
- Deployed through the pipeline, with the change logged against the requirement.
Governance
What lands on your desk, and how often
On a recurring basis you receive
- A fortnightly increment and demonstration
- A written progress note against agreed scope
- An open risk and decision log
- A change register with costs
- Environment and uptime reporting once live
- A quarterly review against the original business case
Governance is only useful if it is boring. A status report that needs interpreting has stopped doing its job.
See the model applied to your own delivery
Bring one live requirement and we will walk you through how it would be sized, agreed, built and recorded.