People ask which models I use to build things. I think that's the wrong question. What makes building easier than ever is the method around the model: a few rules that decide when a piece of work is done, and who is allowed to say so.

I call the method Helix-lite, after Shopify's Helix, which inspired it. This is how it works, and why I prefer to build this way. I'll use an app I built, Pip Pip, to demonstrate.

I decide where I can see

Before any code, I designed the whole app as an interactive prototype: every screen, every state, every sentence in English, Swedish and Danish. That prototype is the spec. The AI copies the text from it and doesn't rewrite it. If the prototype and the written rules disagree, it asks me. It doesn't guess.

The reason is simple. I can judge a screen. I can't judge a function. So I make my decisions in a place where I can see them, and the code has to match.

The same goes for promises. Pip Pip says "No GPS tracking. Ever." and "Stored in the EU." Those are written into the project as rules, and a script checks what it can on every change: no location packages, no trackers, servers in EU regions. A promise that lives only in my head will be broken by a helpful AI on a Tuesday afternoon.

It also makes saying no easier. We left a QR scanner out of the app because the Android library behind it would have sent usage data to Google. The rule was already written, so the discussion took one message.

Small checkpoints, four gates

The app is built one small checkpoint at a time, and a checkpoint is done only when it passes four gates:

1. Behaviour. One command runs every check: the rule checks, the type checks, the tests. It has to end in green.
2. Screens. The AI takes a screenshot of the app and of the prototype in the same state, and fixes every difference it can.
3. Review. A separate reviewer has to approve the exact version being shipped. More on that below.
4. Me. I try it on my own phone.

Each checkpoint ends as one pull request, written for me in plain words: why, what changes for families, how it was checked, the risk and how to undo it. The next checkpoint doesn't start until I say go.

I'm not aiming for a perfect first attempt. I'm aiming for work that reliably gets to right, in pieces small enough that a mistake is cheap.

The author doesn't mark its own homework

The reviewer is a second AI that starts with a clean slate. It sees the code, the project rules and the spec. It doesn't see the conversation that produced the code, so it can't be talked into anything. Its instructions say that approving weak work is the failure it exists to prevent.

A small guard in the project blocks a pull request unless an approved review exists for that exact version. A new change after approval means a new review. The builder can't write the review itself and can't merge any other way.

This has caught things I would never have found. In the second checkpoint the reviewer showed that a faked connection request would expose a parent's name and phone number. In the third it showed how to get around the limit on sign-in text messages. Both looked finished to me.

A review also has to end. Later rounds look only at what changed. Problems that were already there go to the backlog and don't block. If the fourth round still finds something blocking, the work stops and the approach comes to me. That happened once, on the lock-screen build. We froze it to fixes only, and it shipped.

My job: decide, test, remember

Three things stay with me, and none of them is reading code.

Decide. I ask for one question at a time, in simple language, with a recommendation. Most of my answers are a few words: "Yes, keep per trip." Each one goes into a decisions log with the reason. Many of my decisions are a no.

Test. I try every checkpoint on my own phones. That is where the bugs no test finds turn up. The keyboard covered the "Send code" button. A settings screen was an empty placeholder until I tapped it. One iPhone build crashed on opening a sheet that had passed every screen test.

Remember. Every one of those became a line in a Lessons list that the AI reads before each checkpoint. A rule that gets broken twice becomes an automated check. Open work lives in a backlog in the project, never in one chat's memory, because I run several AI sessions side by side and a chat forgets.

This third part is where the method starts to pay back. The project gets harder to break the longer I work on it.

The same shape at a very different size

The team that builds Claude Code works in much the same shape. Their question is no longer "did someone read the code?" but what could go wrong with a change, and which check, automated or human, is the right one to catch it.

That was a relief to read. It turns out the people with the most practice have stopped treating that as the test.

Some of this I had from the start. Some I took from the article, and some they do far better. They measure everything; I count review rounds on my fingers.

Three things I do differently, on purpose or by necessity:

• My human check is on the phone, not in the code. Their engineers still review the risky changes themselves. I can't. So the proof has to be something I can judge: a screen, a number, a sentence about what changes for families.
• My undo is weaker. They have feature flags and staged rollouts. I have small pull requests and a handful of testers before the stores. It's the gap I'd close first if the app grows.
• Nothing runs overnight. Their agents fix review comments while people sleep. I keep the AI on a short lead until the Lessons list has earned more.

If you're starting today

You don't need to be an engineer to build this way, but you do need to act like an owner. What I'd tell another product person:

• Design it first, somewhere you can see it. Make that the spec.
• Write your promises as rules a machine can check.
• Build in small pieces, and define "done" before you start.
• Never let the AI that wrote the work be the one that approves it.
• Test on the real device yourself. Screenshots lie in the gaps.
• Write down every decision and every lesson, in the project, not in a chat.
• Ask before anything that costs money, reaches real people or can't be undone.

The AI writes the code. I decide what Pip Pip is.

I wanted a place on the internet that felt like mine. Somewhere to put the things I make when nobody has asked me to make them.

Most of my working day goes into products for other people, and I enjoy that work. This site is for the rest, the projects I start because I'm curious about something and want to see where it goes.

So I built my desk. The real one sits in front of a yellow brick wall, with a copper pipe running along it and a green leather top on an old oak desk. You're sitting in my chair right now. Drag to look around and click on whatever catches your eye.

Everything on the desk leads somewhere. The phone opens Pip Pip, the first app I've built and put in the hands of testers. The books on the shelf are the ones I keep going back to, and the polaroids are photos I took. Press play on the speaker and see how many notes you can catch.

I want it to feel like you just missed me. The coffee is still warm, and my phone is reminding me to water the plants. I stepped out for a minute and you wandered in.

The site is also an experiment in how I build now. I described what I wanted to Claude, we mocked it up together and then made it, one small change at a time. I don't write code for a living. A couple of years ago something like this would have been out of reach for me. I want to explore what happens when the distance between an idea and a working thing gets this short.

I'll write here about building products and working with teams. Expect notes written while I'm still figuring things out.

If you want to say hello, the sticky notes on the monitor have my email, LinkedIn and X.