Delivery model
A delivery model you can inspect at every stage
Digital systems fail more often through unclear scope and untested assumptions than through technology. Our process is built to remove both early.
Phases
Five phases. A decision at each one.
Each phase ends with something you can read and a decision that is yours to make. Phases can loop: when a review changes the scope, the work goes back a step rather than carrying the change silently forward.
Phase 01 of 05
Discover
Objectives, constraints, existing systems and the decision the work must support.
- What leaves the phase
- A written scope: the objective, the systems involved, the constraints we found and what is deliberately out of scope.
- What you are asked to do
- Confirm the objective, name the people whose approval is required and flag anything the scope has misread.
The gate
Written scope agreed before build
Approved: the work moves to Design. Changed: it returns a step rather than carrying the change forward.
Phase 02 of 05
Design
Structure, interface and data contracts defined before implementation begins.
- What leaves the phase
- The structure, the key screens and the data contracts the build will follow, in a form you can read without a demo.
- What you are asked to do
- Review against your awkward cases rather than the ideal one, and say which parts must not change.
The gate
Client review of structure and direction
Approved: the work moves to Build. Changed: it returns a step rather than carrying the change forward.
Phase 03 of 05
Build
Typed, reviewable implementation in small increments against real cases.
- What leaves the phase
- Working increments you can open and use, built from typed, reviewable code against real examples.
- What you are asked to do
- Use each increment and report what is wrong while it is still cheap to change.
The gate
Working increments, not slide decks
Approved: the work moves to Integrate. Changed: it returns a step rather than carrying the change forward.
Phase 04 of 05
Integrate
Connection to live systems with staging and production kept clearly separate.
- What leaves the phase
- The system connected to the live tools it depends on, with staging and production kept visibly separate.
- What you are asked to do
- Provide the access the connection needs and name who signs off before anything goes live.
The gate
Verification before anything goes live
Approved: the work moves to Improve. Changed: it returns a step rather than carrying the change forward.
Phase 05 of 05
Improve
Measure, correct and extend once the system is carrying real work.
- What leaves the phase
- Corrections, measurements and agreed extensions once the system is carrying real work.
- What you are asked to do
- Agree what is monitored, who is contacted when something fails and how changes are raised.
The gate
Agreed maintenance and support terms
Improvement continues in agreed cycles, each reviewed the same way.
Phase 01
Discover
Objectives, constraints, existing systems and the decision the work must support.
- What leaves the phase
- A written scope: the objective, the systems involved, the constraints we found and what is deliberately out of scope.
- What you are asked to do
- Confirm the objective, name the people whose approval is required and flag anything the scope has misread.
- The gate
- Written scope agreed before build
Phase 02
Design
Structure, interface and data contracts defined before implementation begins.
- What leaves the phase
- The structure, the key screens and the data contracts the build will follow, in a form you can read without a demo.
- What you are asked to do
- Review against your awkward cases rather than the ideal one, and say which parts must not change.
- The gate
- Client review of structure and direction
Phase 03
Build
Typed, reviewable implementation in small increments against real cases.
- What leaves the phase
- Working increments you can open and use, built from typed, reviewable code against real examples.
- What you are asked to do
- Use each increment and report what is wrong while it is still cheap to change.
- The gate
- Working increments, not slide decks
Phase 04
Integrate
Connection to live systems with staging and production kept clearly separate.
- What leaves the phase
- The system connected to the live tools it depends on, with staging and production kept visibly separate.
- What you are asked to do
- Provide the access the connection needs and name who signs off before anything goes live.
- The gate
- Verification before anything goes live
Phase 05
Improve
Measure, correct and extend once the system is carrying real work.
- What leaves the phase
- Corrections, measurements and agreed extensions once the system is carrying real work.
- What you are asked to do
- Agree what is monitored, who is contacted when something fails and how changes are raised.
- The gate
- Agreed maintenance and support terms
The ledger describes how work is organised. It does not set durations or prices; those are agreed in writing for each project.
Your part
Three questions to bring to a review
A review is not a presentation. These three questions tend to surface the problems that are expensive to find later.
- 01
Show me this with our real work in it
A review against sample content hides the awkward cases. Ask to see your own records, your longest document name, your messiest address field.
- 02
What are you waiting on from us?
Most delays are dependencies: an access credential, an approved document, a decision only one person can make. Dependencies are listed at every review.
- 03
What has changed since the agreed scope?
Changes are raised before they are built. A review is the moment to confirm what moved, what it affects and whether it belongs in this phase.
Before release
What has to be true before anything goes live
Release is a decision, not an event that happens because the work looks finished.
Staging
Visibly marked, kept apart from live data. Journeys and failure states are exercised here.
Named human
release decision
Production
Changes arrive only after that decision. Nothing experimental runs quietly against it.
The journeys that matter are exercised
The paths a real user takes are run end to end, including the ones where something goes wrong: an empty result, a failed connection, a rejected input.
Staging and production stay separate
Test work does not run quietly against live data, and a staging environment is visibly different from the live one.
A named person approves the release
Automation prepares the release. A person with the authority to accept the consequences decides that it goes out.
Principles
How we make decisions
Structure before surface
Content model, data contracts and states are decided before visual polish, so the design has something real to express.
Small verifiable increments
Work is delivered as working slices you can open and judge, rather than a long silent build followed by a reveal.
Evidence over assertion
Claims about performance, quality or completeness are backed by something checkable: a test, a measurement, a log.
Human approval where it matters
Automation and AI assist the work. Decisions with commercial, legal or safety weight keep a named human gate.
Built for handover
Typed components, consistent naming and a clean repository structure so your team or another developer can continue.
Separate environments
Staging and production are visibly different. Nothing experimental is left running quietly against live data.
Engagement
How work is scoped and billed
- One-off build phases are scoped, quoted and delivered against a written scope.
- Ongoing maintenance, hosting supervision and improvement work is handled on a retainer.
- Changes outside an agreed scope are raised before they are built, not after.
- Access to accounts, domains and repositories is documented and returned at handover.
What you take away at handover is agreed for each project: the code and content are yours, and the specific accounts, documentation and training that come with them are written into the scope rather than assumed.
Ready to scope something?
A project brief gives us enough to propose a sensible first phase, or to tell you honestly that a smaller step would serve you better.
Start a project briefRead the Hapis delivery constitutionStarting point
A useful first phase
Most work starts with one phase that stands on its own. Four things are agreed before it begins.
- The result
- A standalone outcome you keep, whether or not a larger build follows: a scope, a working slice or a decision made on evidence.
- The inputs
- The documents, access and people we need from your side, listed before the phase starts so nothing stalls halfway.
- The constraints
- What the phase will not cover, and the existing systems, policies or approvals it has to respect.
- Complete when
- The written condition that ends the phase, agreed in advance so completion is not a matter of opinion.