RESOLV

Our approach

A delivery standard you can inspect.

Every engagement follows the same four stages: Assess, Build, Prove and Operate. The stages are not a ceremony. Each one exists to produce specific evidence, and work does not move forward until that evidence exists.

Engagement models

Between stages sit quality gates with written criteria agreed at the start. A gate is passed by showing the artefacts, not by a status update, so the client can see at any point what has been done, what has been tested and what remains.

The four stages

Assess. Build. Prove. Operate.

Stage 01

Assess

Establish the facts before committing to a design: what exists today, what the organisation needs, and what could go wrong.

Activities

  • Stakeholder interviews with business owners, operators and risk functions
  • Review of current architecture, data flows, integrations and dependencies
  • Threat modelling and risk assessment of the target scope
  • Definition of measurable acceptance criteria and service levels
  • Delivery plan with stages, gates and exit points

Evidence produced

  • Current-state architecture and data-flow diagrams
  • Risk register with owners and proposed treatments
  • Agreed scope, acceptance criteria and non-functional requirements
  • Delivery plan and gate criteria signed off by the client
Stage 02

Build

Deliver working software and infrastructure in small, reviewed increments, with tests written before the code they protect.

Activities

  • Short delivery cycles with a demonstrable increment at the end of each
  • Tests written first, including tests for failure and abuse cases
  • Peer review of every change before it is merged
  • Infrastructure and configuration defined as code in version control
  • Automated security checks in the build pipeline
  • Regular demonstrations to the client with real data where permitted

Evidence produced

  • Version-controlled source and infrastructure code owned by the client
  • Automated test results for every merged change
  • Review records for every change
  • Pipeline security scan results with triage decisions
Stage 03

Prove

Demonstrate, with independent testing and documented results, that the system meets its functional, security and resilience requirements.

Activities

  • Penetration testing of applications, interfaces and infrastructure
  • Performance and load testing against agreed peaks
  • Backup restoration and failover exercises
  • Accessibility testing against WCAG 2.2 where users are involved
  • User acceptance testing with the client team

Evidence produced

  • Penetration test report with findings, remediation and retest results
  • Performance and recovery test results against stated objectives
  • Accessibility conformance findings
  • Signed user acceptance record
  • Operational documentation and runbooks
Stage 04

Operate

Run the system under defined service levels, improve it continuously, and build the client team's ability to run it themselves.

Activities

  • Monitoring, alerting and on-call response against agreed service levels
  • Patching, backup verification and capacity management
  • Incident management and post-incident review
  • Regular service reporting and improvement planning
  • Knowledge transfer and training for the client operating team

Evidence produced

  • Service reports against agreed service levels
  • Incident records and post-incident reviews with actions
  • Patch and backup verification records
  • Training records and handover checklist

Quality gates

Nothing moves forward on trust alone.

Gate 1: Ready to build
Scope, acceptance criteria and risk register agreed in writing; architecture reviewed; delivery plan signed off by the client sponsor.
Gate 2: Ready to merge
Applied to every change: tests written and passing, peer review completed, pipeline security checks triaged, no unexplained reduction in test count.
Gate 3: Ready to release
Penetration test complete with critical and high findings remediated and retested; performance and recovery objectives demonstrated; acceptance testing signed.
Gate 4: Ready to operate
Monitoring and alerting live; runbooks reviewed by the operating team; backups restored successfully; support model and escalation paths agreed.
Gate 5: Ready to hand over
Client team trained and able to perform routine operations and incident first response unaided; documentation, source and credentials transferred.

Principles

What never changes.

Evidence over assurance

Progress is shown through test results, review records and working software, not through status reports.

Failure first

We test how a system fails before we trust how it succeeds, and we write the test before the fix.

Reversible by default

Every migration and release has a rollback path that has been exercised, not merely documented.

The client owns everything

Source code, infrastructure definitions, documentation and accounts belong to the client from the first day.

Tell us what can't fail.

A senior engineer reviews every enquiry and replies within one business day.