Selected projects
Work that had to hold up.
Six engagements across regulated and operational environments — with the context, the difficult decisions and the measured result.
Work that had to hold up.
The projects below are representative of the engagements we undertake: complex operating processes, fragmented systems, regulatory or public responsibility, and a need for a result that can be measured.
Client names are withheld where confidentiality applies. Each case describes the context, the architecture, the difficult decisions and the operational outcome. The figures are client-reported against an agreed baseline.
We do not present a portfolio of logos as a substitute for evidence. The useful question is whether the pattern of the work matches your problem.
Six engagements, six different constraints.
Each page includes at least two project visuals and a detailed account of the problems encountered and resolved.
Regional health referral intake
Replacing a paper and email referral process across a distributed clinic network with a secure intake platform that made urgency, completeness and status visible.
Fleet visibility and exception control
Unifying four telematics platforms and a manual dispatch spreadsheet into one operational view for a 480-vehicle logistics fleet.
Regulatory reporting fabric
Replacing a nine-day spreadsheet reporting cycle with a governed data platform that made every reported figure traceable to its source.
Citizen case management
Consolidating seven program areas and a legacy database into a single case-management platform with accessible citizen access and audit-ready decisions.
Energy field operations platform
Giving 260 field technicians an offline-first inspection and asset-capture tool that replaced paper forms and improved the quality of maintenance data.
Student services hub
Connecting three campuses and a fragmented enrolment process into a single student view, reducing administrative effort and conflicting advice at peak periods.
What these projects have in common.
The sectors differ. The failure patterns and the disciplines that resolve them are remarkably consistent.
A system, not an app
Every successful outcome depended on data ownership, integration contracts and an operating model, not just a new interface.
Constraints before code
The most important decisions were made before build: identity, boundaries, failure paths and the definition of done.
Adoption is design
A platform that is slower than the workaround will not be used. We design for the real task, including the exception path.
Handover matters
Each engagement ended with documentation, operational ownership and a support path. The system had to survive without the project group.
How we report an outcome.
Project outcomes are easy to overstate. A percentage without a baseline is a marketing number, not evidence. We agree the measures, the baseline and the measurement method before delivery, then report against them after the system has been in operation long enough to produce a stable result.
Where a client cannot share a commercial metric, we use operational measures that can be observed: time to complete a task, volume of manual rework, number of unresolved exceptions, availability, adoption or audit completeness.
- The baseline and the source of the data.
- The definition of the measure and who owns it.
- The period over which the result was observed.
- The factors outside the project that may have influenced the result.
- What remains unknown or unmeasured.
This is also why our project pages include what we would do differently. An outcome is more credible when the delivery story includes the decisions that were difficult, not only the ones that worked.
How to read a project case study.
A case study is useful when it lets you compare the constraint, the decisions and the evidence to your own situation. It is less useful when it is a list of technologies and a logo. We write each project page around the problem, the architecture, the difficult moments and the measured result.
The client details are withheld where confidentiality applies. The figures are client-reported against an agreed baseline, and the lessons include what we would do differently. That is deliberate: a project that reports only success is not a reliable guide to the next project.
- Start with the operating context, not the technology stack.
- Look for the decisions that changed the outcome.
- Compare the measures and the baseline to your own environment.
- Read the lessons as carefully as the results.
If a case looks similar to your problem, the most useful next step is a conversation about the differences, not a copy of the solution.
Have a project with a difficult constraint?
Tell us what has to be true when the system is live. We will help shape the path.