People sometimes ask me how I built something, and the question has a strange energy to it. Not “how does it work?” but “how is it that you built it?” / “how do you have the time?” – as if building things is reserved for a particular kind of person, and a lawyer or busy father isn’t it.

I think that’s wrong. I think the barrier between “I have an idea” and “it exists on the internet” has never been lower. And I think more people – especially people who aren’t engineers – should just build things.

The evidence

Here is a partial list of things I have shipped:

I built STRIDE – a digital regulation tracker that monitors draft laws across dozens of jurisdictions. It’s used by in-house legal teams at large companies. It’s a proper product, with users and infrastructure and a roadmap. I built it because we were tired of regulatory horizon-scanning being a PDF someone emails around once a quarter.

I built AI Collider – a visual diagnostic for comparing AI strategies across 72 dimensions – because I wanted to see where AI policies agree and diverge, not read about it in a table.

I built AI Contract.ing because the Society for Computers and Law published useful AI Act template clauses as a 60-page PDF, and a 60-page PDF is a bad way to use template clauses.

I built Magic Story Club because my kids wanted bedtime stories about themselves.

I built Operation GoGoGo because getting three children out of the house on a school morning is a logistics problem, and logistics problems deserve dashboards.

I built LessIsMortgage because I wanted to compare mortgage scenarios side by side and nothing free let me do it properly.

I built GoodKnight because my son and I play chess on a Kindle at bedtime, and there wasn’t a single over-the-board chess game for Kindle. Then I added Stockfish so we could learn to spot pins and forks.

None of these required a computer science degree. None of them required a team. Most of them started as “this annoys me” or “wouldn’t it be nice if.”

What actually matters

The hard part of building things is no longer the code. The effort used to be so high, most things would have to be a business, and so was about knowing what to build that would be valuable to others. I now think that great value, and products, can readily just come from solving personal irritation, and continuing from there.

If you work in a domain – law, finance, education, whatever – you have something most engineers don’t: deep context. You know which problems are real and which are imagined. You know what “good enough” looks like. You know who will actually use the thing, because you’re one of them.

The tools have caught up. Open source gives you the components. Cloud hosting means you don’t need a server room. AI assistants will pair-program with you, explain error messages, and scaffold things you’ve never built before. The distance between “I wonder if I could…” and a working prototype is measured in hours now, not months.

You will write bad code. Your first version will be ugly. You will deploy something and immediately find a bug. This is normal. This is how it works for everyone. The difference between someone who builds things and someone who doesn’t is not talent – it’s a habit, the development of a muscle, and tolerance to increase your surface area for being criticised.

Why this matters

I write better technology contracts because I’ve deployed my own infrastructure. I give better advice on data protection because I’ve built systems that process personal data. I understand AI regulation better because I’ve built AI products.

The legal profession talks constantly about legal technology, but an uncomfortable amount of that conversation happens at a safe distance from actual technology.

Building things changes how you think. Not because writing code is inherently enlightening, but because shipping something real, something with users, something that can break, forces a kind of honesty that reading about technology never does.

So build something

Pick a thing that annoys you. A process at work that’s held together with email. A spreadsheet that should be an app. A PDF that should be a website. An evening routine that deserves a dashboard.

Build it badly. Ship it. Improve it. Show it to someone.

You can just build stuff. Here’s my little contribution.