Delivery process
A documented process, not a description of one.
This is the page a procurement reviewer or technical due-diligence team reads most carefully. Every phase below names its artefacts and the gate that has to be signed before the next phase opens.
- 01
Discover
Establish what is actually being built, and why.
Activities
- Stakeholder interviews
- Current-state analysis
- Requirement elicitation
- Success-metric definition
Artefacts produced
- Requirements document
- Scope boundary
- Risk register
Exit gate
Client sign-off on scope and success criteria
- 02
Design
Define the experience before building it.
Activities
- User flows
- Wireframes
- UI design
- Design system
- Prototypes
Artefacts produced
- Design system
- Clickable prototype
- Accessibility specification
Exit gate
Design approval and usability validation
- 03
Architect
Choose the technical foundation deliberately.
Activities
- Solution architecture
- Data modelling
- Integration mapping
- Security threat model
Artefacts produced
- Architecture document
- Decision records
- Data model
- Security review
Exit gate
Architecture review sign-off
- 04
Build
Ship working software incrementally.
Activities
- Two-week sprints
- Daily standups
- Mandatory PR review
- Automated tests
- Sprint demos
Artefacts produced
- Working increments
- Sprint reports
- Updated documentation
Exit gate
Demo acceptance per sprint
- 05
Assure
Verify against requirements before release.
Activities
- Functional & regression testing
- Integration testing
- Performance testing
- Security & accessibility testing
Artefacts produced
- Test reports
- Defect log
- Performance baseline
- Release notes
Exit gate
Zero open critical or high defects
- 06
Operate
Keep it running, and keep it improving.
Activities
- Deployment
- Monitoring setup
- Incident response
- Patching
- Enhancement cycles
Artefacts produced
- Runbooks
- Monitoring dashboards
- SLA reports
Exit gate
Ongoing against agreed SLA
Governance & communication
A fixed cadence, so nobody has to chase an update.
| Cadence | Ceremony | Covers |
|---|---|---|
| Daily | Standup | Blockers surfaced same day |
| Weekly | Written status report | Progress, risks, decisions needed |
| Bi-weekly | Sprint demo | Working software, not slides |
| Monthly | Steering review | Scope, budget, roadmap |
| Quarterly | Engagement review | Value delivered, direction |
Escalation matrix
A named route when something goes wrong.
| Level | Owner | Response |
|---|---|---|
| Level 1 | Delivery manager | Same business day |
| Level 2 | Engineering lead | Within one business day |
| Level 3 | Company leadership | Within two business days |
Response times above are our standard commitment. Engagement-specific SLAs are agreed in the SOW and can be tighter.
Quality standards
What “done” means, written down.
Code review
Every change goes through pull request review by an engineer who did not write it. No direct commits to protected branches.
Automated testing
Unit and integration tests run on every push. A failing suite blocks the merge rather than generating a warning.
Static analysis
Linting and type checking run in CI. Style is settled by tooling so review time goes to design, not formatting.
Definition of done
Code merged, tests passing, documentation updated, acceptance criteria demonstrated, and deployed to a reviewable environment.
Change management
Scope changes are raised as written change requests, estimated, and approved before work starts — never absorbed silently.
Documentation
Architecture decisions are recorded as they are made. Runbooks are written during the engagement, not reconstructed at handover.
Want to see the artefacts?
We can walk your technical or procurement team through real examples of the documents this process produces — architecture records, sprint reports, test plans, and runbooks.
- First response within one business day
- NDA in place before any disclosure
- Scoped proposal, not a generic quote