Delivery Standards
The engineering bar we hold ourselves to — defined before the build starts, not claimed after it.
- Reviewed
- Every Change
- Automated
- Test Gates
- OWASP
- AppSec Baseline
- WCAG 2.1 AA
- Accessibility Target
Nothing Merges Without Review
Every change goes through pull request review before it reaches a shared branch. Review covers correctness, security and maintainability, and the reviewer is never the author.
- Pull request review on every change
- Protected branches in CI
- Conventional commit history
- No direct pushes to main
Automated Tests Are a Gate, Not a Suggestion
Unit, integration and end-to-end tests run in the pipeline, and a failing suite blocks the deploy. Coverage targets are agreed per project and reported rather than assumed.
- Automated unit and integration tests
- End-to-end coverage on critical paths
- Failing tests block deployment
- Coverage reported per project
Security Runs Through the Build
Dependency scanning, secret detection and static analysis run in the pipeline. Changes touching authentication, payment or personal data get an additional manual review.
- Dependency and licence scanning
- Secret detection in commits
- Static analysis in CI
- Extra review on sensitive modules
Accessibility Is a Target, Not a Footnote
Interfaces are built to WCAG 2.1 AA as a design target: semantic markup, keyboard operation, visible focus and contrast that holds. On public-sector work this is a requirement rather than a preference.
- WCAG 2.1 AA as the build target
- Keyboard and screen-reader testing
- Contrast and focus-state review
- Accessibility noted in handover docs
Handover Is Documented
Delivery includes architecture notes, environment setup, runbooks and known limitations. The goal is that your team can operate and extend the system without us in the loop.
- Architecture and decision records
- Environment setup documentation
- Operational runbooks
- Known limitations written down
Delivery Is Measured
Where a project runs continuously, we track the standard delivery metrics — deployment frequency, lead time for change, change failure rate and time to restore — so improvement is visible rather than asserted.
- DORA metrics where applicable
- Baseline captured at project start
- Change failure rate tracked
- Metrics reported to the client
Ask Us the Hard Questions
Bring a security questionnaire, an accessibility requirement or a delivery concern — we would rather answer it before the contract than after.