Selected work
The engineering problem, not the logo
Each of these describes a real constraint, the design decisions that came out of it, and what we would do differently. Written for someone technical who wants to know how we think.
How we write these
Three rules, applied to every case study
They cost us some persuasiveness. We think they buy more than they cost.
- 01
Clients are anonymised unless we have permission
Most of our work sits inside systems clients would rather not discuss publicly. We would rather write a useful case study about an anonymous company than a vague one about a named client.
- 02
No numbers we cannot evidence
You will not find percentage improvements or revenue figures here. Where clients have those numbers, they are commercially sensitive, and a metric you cannot see the derivation of is decoration rather than evidence.
- 03
Including what went wrong
Each case study contains at least one thing we got wrong, nearly got wrong, or found that nobody wanted to hear. Those are the parts worth reading, and they are what you would actually be buying.
Next step
Your situation is not in this list.
It never is. Bring the specific process that is causing you the most pain and we will tell you what we would do about it, and whether it resembles anything we have built before.