For two years I built things for myself, for TWO Design, and for friends who asked nicely. Then an organisation asked me to come and do it inside theirs, on a contract, with deliverables and a review cadence and everything.

This is the first engagement of its kind I've taken, it's currently live, and it has changed how I think about all of it.

The Engagement

The client is a fifteen-person social impact consultancy working across Kenya, India, Colombia and the United States, with a decade of delivery behind them — several hundred projects, largely for UN agencies and international foundations. They're not a technology company and have no intention of becoming one. They run on Google Workspace, a finance system, Slack and a design tool, like most organisations of their size and seriousness.

I'm going to keep them anonymous here while the work is in progress. What's useful to describe isn't who they are, it's the shape of the problem, and the shape is common to nearly every professional services organisation I've ever worked with — including my own.

The engagement is six months. It's called a friction audit and an organisational intelligence roadmap, which is a longer way of saying: find where the time goes, then build the things that stop it going there.

The Audit Comes First

The instinct, when an organisation asks about AI, is to arrive with a list of impressive things it can do. I think that's the wrong end entirely, and it produces the outcome everyone has now seen at least once: a tool that demos beautifully and is quietly abandoned by week five.

So the first phase isn't building. It's finding out, specifically and unsentimentally, where this particular organisation loses hours and loses knowledge. Not where AI would look clever. Where the pain already is, measured in the actual complaints of the people doing the work.

You get very different answers than you expect. Almost none of the real friction was in the places anyone would have put on a slide.

Six Frictions

We found six. I'd wager most organisations of this kind would recognise five of them:

Knowledge lost at project close. The team moves to the next thing before anyone documents what happened in the last one. Six months later nobody can reconstruct why a decision was made.

Cash flow assembled by hand. Hours every month, pulling the same numbers out of the same systems into the same spreadsheet.

Proposals written from memory. "Have we done anything like this before?" is answered by whoever happens to have been there, if they're still around and if they happen to be in the room.

Fifteen timesheets consolidated manually. No automation, no validation, every month, forever.

Client calls with no structure after them. The insight lives in whoever took the best notes, in a document nobody else opens.

Case studies written from thin air. Produced months later from recollection, which is why they're late and why they're vague.

None of those are AI problems. They're record-keeping problems, and record-keeping is the thing this technology is genuinely, unglamorously good at.

How I Build Inside Someone Else

A few rules I've held to, most of which I arrived at the hard way.

Deterministic logic stays separate from the model. Numbers, flags and aggregations come from code. The model handles language and orchestration. When a finance lead asks why a figure says what it says, the answer has to be a function they can point at, not a probability distribution. This one is non-negotiable and it rules out a lot of architectures that would otherwise be quicker.

The data doesn't move. No migration, no new home for everything. Their files stay where their files already are. What gets built is a layer that retrieves, indexes and processes what it's allowed to touch. An engagement that begins by asking an organisation to relocate a decade of work has already failed.

Permissions mirror the permissions that exist. If someone can't open a folder, the system cannot surface its contents to them. Salary data doesn't leak into a general search because someone phrased a question cleverly. This sounds obvious and is the single easiest thing to get catastrophically wrong.

Fortnightly increments, reviewed and used. Each module gets built, then used by real people, before the next one starts. Six months of building followed by one big reveal is how you find out in month six that you built the wrong thing.

Show, don't describe. This client responds to things they can click on and gets glazed eyes at anything else. Most people do. I've stopped writing explanatory documents where a two-minute demo would do.

The Fluency Problem

Running alongside the building is the part I underestimated: teaching the team to use any of it.

A tool nobody opens is worth precisely nothing, however elegant the architecture. So there's a parallel track — leadership first, because adoption that isn't visibly endorsed at the top doesn't happen, then two pilot champions from different functions, then the wider team. Workshops, one-to-one sessions, and a self-serve onboarding microsite that replaced a fifty-minute screen-share I was otherwise going to run individually for fifteen people.

That microsite is a fair summary of the whole engagement, actually. The bottleneck wasn't the technology. The bottleneck was me, doing the same call over and over. So I automated myself out of it.

This is also where my day job turns out to be the relevant qualification. Twenty years of explaining design decisions to clients who don't design is decent preparation for explaining AI to people who don't build. The hard part was never the model.

What Comes Out of It

Some of what gets built stays theirs and stays private, as it should.

One thing didn't. The fifth friction on that list — calls with no structure after them — got a small menu-bar recorder that captured the conversation and filed the transcript somewhere useful. It worked well enough that I wanted it myself, rebuilt it properly, and it's now Minutehand, which anyone can buy.

That's the pattern I'd like to keep. Solve a specific problem for a specific team who will tell you honestly whether it worked, and every so often one of them turns out to be a problem a great many people have.

Where It Stands

Live and ongoing, with four months to run at the time of writing. The early phases are built and in use; the knowledge and proposal work is next; the last stretch is training and handover, because the goal is an organisation that doesn't need me at the end of it.

I'd take on one or two more of these. Not more than that — I still have a studio to run, and this only works if I'm genuinely inside the problem rather than managing it from a distance. If your organisation has its own version of those six frictions, get in touch.