Agree what matters.
Start with the users, business context, system risks and scope. Make the important quality expectations explicit.
Engineering Standards
Quality starts
with the details.
The decisions beneath an interface shape how software behaves, changes and holds up in use. These are the engineering principles that guide our work, with expectations agreed around each engagement.
Beyond the interface
Care you can build on.
Think about the people using it, the systems around it and the changes still to come.
Where we put the care
The foundations behind the experience.
Explore the practices and review material behind each standard. Their depth depends on the system, its risks and the scope of the engagement.
Architecture that can change
Understandable boundaries and explicit contracts give a system room to evolve as the work changes.
Architecture that can change
In practice
- Define responsibilities across interfaces, services and data.
- Make dependencies and important trade-offs explicit.
- Choose complexity that fits the problem and the people maintaining it.
What makes it reviewable
- System boundaries and data-flow diagrams.
- Recorded decisions, assumptions and dependencies.
- Contracts and documentation that support the next change.
Security from the foundation
Identity, permissions, validation and data handling are part of designing the system from the start.
Security from the foundation
In practice
- Check permissions where actions and data are accessed.
- Validate external input and handle secrets on the server.
- Consider dependency risks, misuse and sensitive information in logs.
What makes it reviewable
- An access model with clear responsibilities.
- Checks for important permission and validation paths.
- Documented configuration and data-handling decisions.
Performance and accessibility
Useful interfaces account for different devices, networks, input methods and access needs.
Performance and accessibility
In practice
- Use semantic structure, clear labels and visible keyboard focus.
- Plan responsive layouts, loading states and reduced motion.
- Review image delivery, request costs and the journeys that need to feel fast.
What makes it reviewable
- Reviews across agreed devices and viewport sizes.
- Keyboard, contrast and accessible-name checks.
- Performance observations and prioritised improvements.
Quality before confidence
Review and testing should give a release a clear basis, including what happens when things go wrong.
Quality before confidence
In practice
- Review meaningful changes and critical user journeys.
- Test permissions, integrations and important failure paths.
- Evaluate AI behaviour and human review points where those features are in scope.
What makes it reviewable
- Tests tied to important behaviour and known risks.
- Review findings and their resolution or agreed limitations.
- A release decision informed by what has been checked.
Operational visibility
People responsible for a live system need a useful way to understand its behaviour and respond to problems.
Operational visibility
In practice
- Identify the events and failures that need to be visible.
- Keep logs useful while limiting sensitive information.
- Agree monitoring, alerting and recovery needs for the environment.
What makes it reviewable
- Meaningful logs and monitoring for agreed flows.
- Documented error and recovery paths.
- Clear ownership of operational signals and follow-up.
Ownership after launch
Documentation, handover and a considered plan for change help software remain understandable after release.
Ownership after launch
In practice
- Document setup, deployment and important system decisions.
- Clarify access, handover and support responsibilities.
- Plan maintenance and continued development around the needs of the live system.
What makes it reviewable
- Usable setup and deployment guidance.
- An agreed handover and support arrangement.
- A visible set of next steps and known limitations.
Part of the delivery
Set expectations early. Keep checking them.
Standards are most useful when they shape daily decisions. We bring them into the planning, review and handover of the work.
Review as we build.
Use working increments, reviews and relevant checks to surface questions while there is room to address them.
Carry the context forward.
Keep decisions, limitations and operating responsibilities visible as the software moves into real use.
Before responsibility moves to users
A release deserves a clear conversation.
Readiness involves the experience, the system and the people who will operate it. These questions help frame that conversation.
The checks and supporting material are agreed for the engagement and the risks of the system.
Discuss your systemDo the important journeys work?
Review the flows people depend on, with the permissions, devices and failure cases that matter.
Can we see what is happening?
Check that important errors and operational signals can reach the people responsible for them.
What happens if something fails?
Discuss recovery, deployment rollback and the support responsibilities relevant to the system.
What still needs attention?
Make known limitations, open decisions and follow-up work visible before agreeing the next step.
Build on a clear foundation
What does your software need to hold up to?
Bring the context, constraints and questions behind your product, website or business system. We can work through the engineering priorities together.