Delivery Approach¶
Our delivery approach is designed to be lightweight, effective, and adaptable. We focus on delivering value early and often, with strong communication throughout.
Engagement lifecycle¶
Discovery¶
Before we write any code, we invest time in understanding the problem. This typically involves stakeholder interviews, technical assessment, and defining clear success criteria. Discovery is where we identify the highest-risk assumptions and begin to resolve them — either through research, through a spike, or through a proof of concept — so that we do not encounter them halfway through delivery when the cost of changing course is much higher.
For technical engagements — particularly those involving infrastructure, cloud platforms, or security configuration — discovery includes a current-state assessment of the existing environment. We understand what is there before we propose what should change.
Public sector engagements often follow Government Service Standard discovery patterns. Where that is the context, we align our discovery approach with the standard's requirements for user research, problem definition, and options development.
Delivery¶
We deliver iteratively, with working software demonstrated regularly. We prioritise ruthlessly and focus on the highest-value items first.
For technical configuration and infrastructure work, delivery follows a consistent four-stage pattern:
Discover — current state assessment, workshops, documentation review.
Define — findings compiled, scope confirmed, success criteria agreed. The client knows exactly what will be addressed before implementation begins.
Design — architecture, configuration, and any IaC built and peer-reviewed before deployment.
Deliver — implementation, validation against agreed success criteria, client handover with documentation and a clear view of next steps.
This framework applies whether the engagement is a two-week infrastructure assessment or a multi-month platform build. The scope changes; the rigour does not.
Transition¶
We do not just build and leave. We ensure proper knowledge transfer, documentation, and support planning so that our clients can maintain and extend what we have built.
Handover is planned from the start of an engagement, not as an afterthought in the final sprint. If the client's team will own the system, we involve them in technical decisions throughout delivery — so there is no gap in understanding when we step away.
For infrastructure and configuration work, the client receives the codebase as a deliverable. They own it. We write it to be maintained by their team, not to require our continued involvement.
Documentation standards¶
We believe in documentation that is useful, not documentation for its own sake. At a minimum, every project should have:
- A clear README with setup instructions
- Architecture Decision Records (ADRs) for significant technical decisions — see the Architecture page for our ADR template and approach
- Runbooks for any operational processes
- Up-to-date API documentation where applicable
For infrastructure and configuration work, documentation also includes what was implemented, why specific decisions were made, and how to manage and extend the configuration going forward.
Quality¶
Quality is built in, not bolted on. We practise code review, automated testing, and continuous integration as standard. We define a clear definition of done at the start of each engagement and hold ourselves to it.
Infrastructure configuration follows the same review discipline as application code. See Infrastructure as Code for the standards we apply to Terraform and cloud configuration.