// solutions

Recurring problems, and how they get approached

These are the situations that come through the door most often. They are written as problems rather than as products, because the right answer differs with every estate.

ERP and CRM integration layer

The problem

Two systems that both hold the truth about a customer, kept in step by people re-typing things, and a monthly argument about which one is right.

The approach

One integration gateway owns the contract between them. Messages are versioned, failures are retried and then parked for a human, and a nightly reconciliation report names every record that drifted.

You probably recognise

Duplicate master data
Manual re-keying between systems
No audit trail across the boundary

Legacy platform modernisation

The problem

A system that still runs the business but that nobody wants to touch: unsupported runtime, no tests, and one person who understands the deployment.

The approach

A seam in front of it, tests written against observed behaviour before anything moves, then component-by-component replacement. The old system stays live until the last component has moved across.

You probably recognise

Unsupported language or framework version
Deployments that only one person can do
Change estimates that keep growing

Operational data platform

The problem

Reporting built on spreadsheets exported by hand, where two departments produce two different numbers for the same question.

The approach

Sources mapped and ingested on a schedule, a dimensional model with definitions written down, and a reporting layer where every figure traces back to the row it came from.

You probably recognise

Manual exports feeding decisions
Conflicting definitions of the same metric
Reports that take days to produce

Internal workflow tooling

The problem

A process running on email threads and a shared spreadsheet, where the state of any given case is whatever the last person remembers.

The approach

The process modelled explicitly — states, transitions, who may do what — with an interface built for the people who use it all day rather than for a demo.

You probably recognise

Process state living in someone’s inbox
No record of who changed what
Onboarding that takes months

// principles

What holds across all of them

The specification is the deliverable first

Code that solves a misunderstood problem is expensive in a way no amount of engineering quality repairs. Nothing is built before the scope is written down and agreed.

Reversible steps

Every migration, every cutover, every schema change has a documented way back. A plan whose only outcome is "it works" is not a plan.

Boring technology where it is load-bearing

We choose tools by what your team can operate after we leave, not by what is interesting to write. Novelty is reserved for the parts of the system where it actually pays.

You own the result

Source code, infrastructure definitions and accounts belong to the client at handover. No component of a delivered system depends on us continuing to exist.

Why there are no case studies on this site

Client work is covered by confidentiality, and a results figure published without the client's evidence behind it is a claim we could not stand behind if asked. So this page describes the shape of the work rather than naming anyone. If you want references before signing, ask during the scoping conversation — where a client has agreed to speak to a prospect, we will put you in touch directly.

Describe your situation