Design lead for AI-built software

Making software got cheap. Knowing whether it's any good didn't.

That's why you can build now. It's also why the hard part moved. For twenty years my job was writing down how good work gets done, so other people could do it consistently: design systems, specs, standards. Now the other people are models.

What changed

Production used to be the constraint.

You decided what to make, then specialists spent months making it. Rework was expensive, so the whole discipline of design existed to specify precisely before anyone wrote code.

Now production is nearly free. You can have a working thing this afternoon. What didn't get cheaper is everything after it works on my laptop: where it lives, where the data goes, who can get in, what it costs at scale, whether it's safe to put real people's information in it, and whether anyone but you can run it.

I'm not here to build it for you. I'm here so it comes out right every time.
Start here

What do you wish AI could do?

Ask anyone already building with AI what they wish it did, and the answers sound like model limitations. They almost never are. The model can usually already do it. What's missing is that nobody wrote down what good looks like here, and writing that down is a design problem, not a prompting one.

“I wish it remembered how we do things”

A documented method. Written once, followed every time.

“I wish it didn't give me something different every time”

A spec. Agree what “done” means before the work starts.

“I wish it looked like us”

A design system. Taste, written down precisely enough to follow.

“I wish I could trust the output”

An evaluation standard. Something checkable, not a vibe.

“I wish it could talk to our other systems”

A protocol. The boring layer that makes everything else possible.

“I wish I could hand this to my team”

Roles, scope, and documentation. The part that outlives you.

The practice

I build the layer that holds the standard.

Methods, made executable

A skill is a written procedure a model follows. I keep a published set for UX work: research, personas, architecture, visual identity. They're UX deliverables, compiled into a form a machine can run.

Taste, tokenised

A design system is what “looks like us” means once it's written down precisely enough to be followed without you in the room.

Standards the pipeline enforces

On a client build I wired accessibility and performance checks into CI against a committed budget file. The standard holds because the build fails, not because someone remembered.

Protocols, so things can talk

In 2017 I open-sourced a message server built on one idea: wrap every message in an envelope the server never needs to understand. That's roughly the bet MCP makes. I got there early by accident, not foresight.

What's underneath

The prototype works. That's where the questions start.

  1. Where does this actually live? Hosting, deploys, domains, environments, and the difference between “it runs” and “it stays up.”
  2. Where does the data go? Databases, backups, and what happens the day it's gone.
  3. Who can get in? Logins, roles, API keys. The thing AI-generated prototypes most often get dangerously wrong.
  4. Is it safe for real people's information? What your board and your auditor will ask, ideally before they ask it.
  5. What does it cost when it works? The bill nobody models at prototype stage.
  6. What happens when it breaks and the AI can't fix it? Telling “the model is confused” from “the system is actually broken.”
  7. Can anyone but you run it? Handoff, documentation, and what happens when you're on holiday.

I answer these for a living. On my current engagement that meant sandboxed execution, per-tenant cost tracking, prompt-injection defences with tests behind them, and moving a live platform onto AWS without losing anything.

Twenty years

Same job the whole time.

I'm a user experience designer. I've been doing the same job the whole time: work out what good looks like, then write it down so it survives contact with other people. The other people used to be developers and creative teams. Now some of them are models.

Before that shift I built the missing layer over and over, without ever calling it that. A protocol so a Kinect, an Arduino and a browser could drive each other. A compiler that read an animator's timeline and emitted production code. My own instrumentation for a platform whose engagement metric was obviously lying. A fidelity framework so a team could agree what “done” meant before starting.

Those four things (protocols, compilers, measurement, and turning messy input into something structured) are, as it turns out, most of what agentic AI is made of.

The work, and what each project introduced

Honestly

What sixteen months of real AI work looks like.

I've been consulting on AI systems for one client since April 2025. In that time we changed direction five times. We evaluated a no-code agent platform and didn't use it. We built a chat platform with agents, MCP tooling and retrieval on top, then spent a season on design and stabilisation instead of features. The thing we're building now started as a document-template tool, got renamed once, and became a sandboxed platform for building real applications.

I'm telling you this because everyone's deck says their AI programme went in a straight line, and nobody's did. If you're building and it feels like you keep restarting, that's not you doing it wrong. That's what the work is right now. It helps to have someone who's been through several of those turns already.

Field notes

What worked, what I abandoned, and why.

All writing

Let's talk

Tell me what you wish it could do.

Or send me what you've built and I'll tell you what's underneath it: what's solid, what will bite you, and what to fix first. Fixed price, clear start and end, no obligation after.