Case study
Orson
An AI-native venture built independently, exploring what software looks like when agents do the work and people stay in charge.
- Client
- Independent venture
- Role
- Founder
- Timeframe
- 2023–
- Sector
- Applied AI
- agent workflows shipped
- 40+
- tasks completed without takeover
- 85%
- hours saved per working week
- 12
Why outside an employer
After six years leading product design at QikServe and then Access Group, I knew what platform-scale software demands. I also suspected the most interesting questions about AI wouldn't get answered inside a portfolio roadmap. Orson is the independent venture I started in 2023 to answer them on my own terms, and it's still running.
Independence matters for this work. Inside an employer, AI arrives as a feature request with a quarter attached and a steering group on top. Outside, you can start from the question rather than the backlog: what should software become when models can interpret, recommend and act? You can also be wrong faster, which matters more than being right slowly.
The bet
Most AI products take existing software and add a place to type. Orson starts from the opposite end. It asks which workflows become possible when an agent can carry real work, then asks the harder question underneath: what does the interface have to do before a person will actually let it?
Trust is the product. A model that's right most of the time, behind an interface that hides which times it wasn't, is worse than no model at all. So the design centre of Orson is the relationship between confidence and control: what the system claims, how it shows its working, and how a person steers, interrupts or takes over without losing the thread.
States traditional software never had
Classic product design assumed deterministic software: same input, same output, forever. Agentic software breaks that assumption, and it needs interface answers for situations with no established pattern yet. These are the states I keep designing for:
- Confidence, and how to show the system's certainty without inventing false precision
- Provenance, so a person can see where an answer came from before relying on it
- Delegation, and the line between act for me and ask me first
- Interruption, because people change their minds mid-task and the agent has to stop gracefully
- Recovery, for the moments the model is confidently wrong and the person needs a clean way back
When an agent acts on your behalf, the interface is the contract.
What operational software taught me about AI
Twenty years of designing operational software is the unfair advantage here. The model is the easy part. The hard part is knowing which decisions people will delegate, which they won't, and how an interface earns the difference. Hospitality taught me that at scale: a platform serving thousands of venues fails loudly the moment it assumes trust it hasn't built.
It also taught me to treat prompts as a design material. Prompt architecture shapes behaviour the way information architecture shapes navigation, and it deserves the same rigour: versioned, tested, reviewed like any other interface decision. Most of Orson's reliability lives there rather than in the choice of model.
The method is prototype-led. Build the working system first, put real tasks through it, and let behaviour decide what survives. Documents and decks can't tell you whether a delegation boundary feels right. Only using the thing can. That's also why Orson stays narrow: depth of trust in a few workflows beats shallow magic across many, and narrowness is what lets a solo builder ship quality.
Team and credits
Orson is a deliberately small operation, and the credits are short.
- Founded, designed and built solo: product strategy, agent workflow design, prompt architecture, interface and the build itself
- Informal critique from designers and engineers I trust, who saw the rough versions and said so
- The open-source and research communities whose tools and published work make a one-person AI venture viable at all
Where it goes next
The roadmap follows the trust question. Each iteration delegates a little more, then measures whether the interface kept the person genuinely in charge or just decoratively informed. Whenever those two come apart, the design is wrong, however impressive the output looks.
Orson also connects my platform past to whatever comes next. The same systems instinct that made one kiosk configurable for thousands of venues is now pointed at intelligent software, and the ventures feed each other: what I learn here flows into the advisory work, and what advisory clients struggle with flows back into what Orson tries next.