Our work

The kinds of problems that reach us

Outlines rather than named case studies: the problem, the shape of the build, and the work involved. Client-specific write-ups follow as approvals come through.

Selected builds

Problems, approach and what we contributed

Nine outlines covering the work that reaches us most often: what the problem was, what we built, and what changed as a result.

Business platform

Internal Operations Console

An operations team was running the day out of shared spreadsheets, with no reliable answer to who owned what. We replaced them with a single console where every job, its owner and its stage sit in one view, and status stopped being something people had to ask for.

Workflow mapping and a data model the team recognised
Role-based access with a full audit trail
Filterable queue views, saved presets and bulk actions
Exports and reporting that replaced the manual weekly roll-up

React
Node.js
PostgreSQL
Role-based access

Web platform

Customer Self-Service Portal

Routine customer questions about where an order is, what was agreed and what is owed were arriving by phone and email, and being answered by hand. A portal put the same answers behind a login, leaving the account team with the exceptions rather than the whole queue.

Account, document and request history in one authenticated view
Self-service actions for the requests that were purely clerical
Notification rules so people are told before they think to ask
Support handover for anything the portal should not decide alone

Next.js
Authentication
REST APIs
Email & notifications

Mobile product

Field Team Mobile App

Crews were completing jobs on paper because the existing tool assumed a connection they rarely had. The replacement captures everything locally, syncs in the background when signal returns, and resolves conflicts without asking the person in the field to arbitrate.

Offline-first storage with deterministic conflict handling
One-handed task, photo and signature capture flows
Background sync with clear, honest queue states
Release pipeline and staged rollout for both app stores

React Native
Offline sync
Push messaging
CI/CD

Data platform

Reporting & Analytics Layer

Every department was producing its own version of the same numbers, and meetings were spent reconciling them instead of acting on them. We built one modelled layer with agreed definitions on top, so a figure means the same thing wherever it appears.

Source mapping and an agreed definition for every headline metric
Scheduled pipelines with freshness and failure alerting
Dashboards for the standing questions, exports for the rest
Access rules so sensitive breakdowns stay with the right teams

Data modelling
ETL pipelines
Dashboards
Access control

Integration

Systems Integration Layer

Several business systems had been wired together over the years by one-off scripts nobody wanted to own. We replaced them with a documented integration layer where every exchange is versioned, retried and visible when it fails.

Contract-first interfaces between systems that had none
Retries, dead-letter handling and replay for failed exchanges
Monitoring that names the failing hop instead of the whole chain
Decommissioning plan for the scripts it replaced

API design
Message queues
Webhooks
Observability

Design system

Product Design System

Several applications from the same company had drifted into different visual languages, and every new screen restarted the same arguments. A shared token and component library gave the teams one source of truth, with accessibility settled in the component rather than at review.

Token scale for colour, type, spacing and elevation
Component states documented with accessibility notes
Contrast and keyboard behaviour verified to WCAG AA
Adoption guidelines and a migration path for existing screens

Design tokens
Component library
WCAG AA
Storybook

Cloud platform

Cloud Environment Rebuild

A hosting setup assembled by hand over several years had become impossible to reproduce, and nobody wanted to touch it. We rebuilt it as versioned infrastructure with repeatable deployments, real monitoring and a rollback that had actually been tested.

Infrastructure defined in code and reviewed like application code
Staged migration with a rehearsed rollback plan
Alerting, log aggregation and dashboards owned by the client
Runbooks and a handover so the team can operate it unaided

Docker
CI/CD
Observability
Infrastructure as code

Modernisation

Legacy Application Modernisation

A long-serving application still ran the business but could no longer be changed safely, and a rewrite was not affordable. We modernised it in place, carving out the parts that changed most often and leaving the rest alone until there was a reason to touch it.

Dependency and risk audit before anything was moved
Incremental extraction behind a stable interface
Characterisation tests written before each change
Parallel running so the switch-over was reversible

Refactoring
Strangler pattern
Test coverage
Migration

Quality engineering

Automated Regression Suite

A long-running application needed a manual checking round before every release, which meant releases were rare and risky. An automated suite wired into the pipeline moved that check to every commit, so shipping became a routine decision rather than an event.

Coverage plan agreed against the journeys that actually matter
End-to-end suite running on every pull request
Flake triage so a red build means something
Release readiness reporting the whole team can read

End-to-end tests
CI
Test strategy
Reporting

How work arrives

Three starting positions, and none of them is a blank page

Most projects reach us in one of these states. Which one you are in changes the first two weeks far more than the technology does.

From zero
There is nothing built yet
An idea, a spreadsheet or a manual process that has outgrown itself. The first job is deciding what the product is before deciding what it is made of.
- Scope is still moving
- No existing codebase
- Needs something usable early
Taking over
Something exists and cannot be changed safely
A working system with no documentation, an absent original team, or a backlog that stalled. We take stock first and only then agree what is worth changing.
- Unclear ownership
- Changes feel risky
- Handover was incomplete
Adding a capability
A live product needs one more layer
An integration, an automation, a reporting layer or a rebuilt flow, added to something already in production without interrupting the people using it.
- Live users to protect
- Fixed release windows
- Existing team to work alongside

Our standard

What “finished” means to us

A build is not done when the feature works on the developer's machine. These are the checks that decide whether something ships.

Interfaces tested with a keyboard before they are called finished
Performance budgets agreed at design time and measured at release
Errors, empty states and edge cases designed alongside the happy path
Automated checks in the pipeline, not a manual round before every launch

Detailed case studies in preparation

We are working through client permissions so we can publish full write-ups with context, constraints and outcomes. In the meantime we are happy to walk through relevant examples directly.

Request a walkthrough

Recognise your own problem in one of these?

Send us the outline. We will tell you how we would approach it, what it would realistically take and where the risks sit.

We reply to every enquiry within one business day.

Start a conversation Read about us