Case studies

Work described honestly, including the parts that went badly.

A case study that reports only success is marketing. Each of these includes what we got wrong and what we would do differently.

Demonstration content

Northbridge Digital Ltd is a fictional organisation created to showcase this website framework. The clients, figures and outcomes below are illustrative and do not describe real engagements.

01 — Financial services

Replatforming a regional lender's customer portal

Eighteen months, phased, with no planned business-hours outage and a 61% reduction in support tickets.

Months

Planned outages

61%

Fewer tickets

The situation

The client operated a customer portal built in 2013 and customised continuously since. No single person understood the whole of it, the vendor's supported version was four major releases ahead, and an upgrade had been attempted twice and abandoned twice. Support volume was rising and the operations team was spending roughly two days a week on password and access issues alone.

What we did

We began with a six-week discovery. The most valuable output was not the architecture diagram but the inventory of customisations, each mapped to the business rule it was implementing and the person who could confirm it. Roughly a third turned out to be implementing rules that had since been withdrawn.

Rather than upgrade, we built a new portal alongside the old one and moved customer segments across in eleven tranches. Identity was federated first, which removed the password and access workload early and paid for a substantial part of the programme before anything else had shipped.

What went wrong

The fourth tranche was rolled back. We had assumed a data-quality rule held for all customer records because it held for every record in the sample, and it did not hold for accounts created before 2011. We lost three weeks and had to write a reconciliation process we should have written at the start.

What we would do differently

Profile the whole dataset, not a sample, before the first migration tranche. Sampling is appropriate for understanding shape; it is not appropriate for establishing an invariant you intend to rely on.

02 — Not-for-profit

Rebuilding a national charity's public website

A fourteen-week rebuild that halved page weight, reached WCAG 2.2 AA, and removed an annual licence the charity no longer needed.

Weeks

52%

Lighter pages

WCAG 2.2 conformance

The situation

The charity's website had accumulated eleven years of content across four content management systems, three of which were still running. An accessibility audit commissioned by a funder had returned 140 issues, a quarter of them serious. Roughly a third of visits came from mobile connections in areas with poor coverage.

What we did

We started with a content audit rather than a design. Of 1,900 pages, 340 had been viewed more than ten times in a year. The charity's communications team made the deletion decisions; we simply made the data available to them.

The rebuilt site is static, with no client-side framework, no external webfonts and no third-party analytics script. Accessibility was reviewed inside each two-week cycle rather than at the end, which meant the final audit returned four minor issues instead of a second list of 140.

What went wrong

We underestimated the redirect mapping. Moving from four systems to one produced several hundred URL changes, and we treated the mapping as a delivery task rather than an editorial one. Two weeks after launch a funder reported a broken link in a printed leaflet, which was entirely foreseeable.

What we would do differently

Treat redirects as content, owned by the communications team, and gather printed and third-party references during discovery rather than assuming the analytics data captures every route into the site.

03 — Manufacturing

An integration layer for a manufacturing group

Replacing nine point-to-point interfaces and a nightly spreadsheet with one observable boundary.

Interfaces retired

Months

Saved daily in reconciliation

The situation

Four sites, three enterprise systems and nine bespoke interfaces, most written by people who had left. Stock figures disagreed between systems every morning and were reconciled by hand in a spreadsheet maintained by one person.

What we did

We introduced a message-based integration layer with explicit, versioned contracts and made every message traceable end to end. Interfaces were migrated one at a time, running old and new in parallel and comparing outputs before the old route was switched off.

The reconciliation spreadsheet was the last thing we removed, not the first. It was the only reliable record of what the correct answer looked like, so it became the test oracle for the migration.

What went wrong

Our first design assumed messages could be processed in order. They could not, because one site's system batched overnight and replayed with original timestamps. We rewrote the processing to be genuinely idempotent and order-independent, which cost about four weeks.

What we would do differently

Assume out-of-order and duplicate delivery from the outset. Designing for it later is a rewrite; designing for it initially costs very little.

Want a reference?

We will introduce you to a client with a comparable problem, including one where the engagement was difficult.

Get in touch