I have a day job. In the evenings and on weekends I make retro games — small games for old systems. It's my side project, done in my spare time, and it's the thing I like doing most.
A while ago I noticed that I hadn't written a line of game code in weeks.
Not for lack of time. Because everything else had eaten it.
A game is not just code
Processing orders. Writing release notes. Answering buyers' questions. Testing, on several systems, again after every change. Planning the next version. And something people call marketing, though mostly it just means reminding them that the game exists at all.
None of it is hard. All of it is constant. And in the two or three hours left in an evening, the urgent always beats the reason you started.
I didn't need better self-discipline or yet another tool. I needed people. I don't have any — the project doesn't support a salary, and it isn't meant to.
How it runs today
At seven in the morning I read a briefing: what ran overnight, what's coming up, what needs a decision. During the day I'm asked at most five times — never with an open question, always with a proposal and a deadline. In the evening, a short report.
In between, an organisation that doesn't exist does the work.
All figures are taken from the live system. No buyer data or amounts appear in them.
Before I built anything, I wrote down what I wanted from it. Four things:
- Visibility. I want to see what's running, at any time, on one page.
- Nothing to maintain. No second system to build and nurse alongside the day job.
- Traceability. Every decision with its reasoning, readable later.
- Hard limits. Some things must not happen without me, whatever the prompt says.
The rest of this article is those four, in practice.
Roles aren't role-play
I built the side project as an organisation. A chief of staff, the only one who talks to me. An orchestrator that distributes work and clears blockers. A controller that watches money and consumption. Plus roles for development, testing, support and writing.
It sounds like playing shop, but it's the heart of the matter: the role is the mechanism by which I grant rights. Whoever is called "Support" may answer buyers' questions — but may not pay an invoice or publish a release. Not because I politely told it so in the prompt, but because the tool for that doesn't exist in its role.
A prompt is a request. A missing tool is a boundary.
Four levels, and one list
Every action has an autonomy level — not every role. The same role researches on its own and still has to ask before a payment.
The A3 list cost me the most work, and it's the reason I trust the system at all.
Money comes first: every payment, no exception, whatever the amount. Then anything binding — promises to buyers, dates, anything with a deadline behind it. Then my name: a release, a first contact, bad news.
And one group I'd advise nobody to cut:
- No role may raise its own autonomy level.
- No role may create another role or change its rights.
- No agent may switch off the log that records what it does.
That isn't in a prompt. It's in code that doesn't offer the action in the first place.
The mechanism that holds it together
When a role has to ask me, it may not do so as an open question. It delivers a short brief: situation, options, recommendation, cost, risk — and two things that make the difference. A deadline. And a default.
If I haven't answered by Thursday, 6 pm, the default applies.
That's not a design flourish. It's the condition under which the whole thing works at all. I'm not available during the day. A system that waits for my answer stands still for eight hours — and then dumps all its questions at my feet in the evening, in exactly the time I wanted for the game.
For A3, the default is always "do not execute". Nothing moves there without me.
Whoever produces doesn't approve
The most effective single measure in the whole system is unspectacular: whoever makes something never signs it off. Code goes to a review role that reads it without the author's context — deliberately in its own session, with fresh eyes. Text goes to an editorial role. Payments to the controller.
An agent that reviews its own work finds it good. Every time.
What it can't do
So there's no wrong impression.
A small model on my own machine does the mechanical part: sorting, classifying, pulling amounts and deadlines out of documents, searching. Everything that involves judgement — planning, prioritising, everything that reaches me, everything legal and financial — goes through a large model.
For most people, I think that split is the right mix. As much as possible stays local. A provider — Claude in my case, but any of them will do — takes the tasks that need real capability, or where the data is low-risk anyway. A small model alone won't run your business. A large model alone sends everything out of the house.
And for the first four weeks it asked too much. That was deliberate. A system that's annoying at the start can be calibrated down in two weeks. A system that's allowed too much too early costs you real damage — and after that you don't trust it any more.
On scale: this is a side project. One person, a few games, evenings and weekends. The system isn't big because the project is big — it's the reason the project can stay small without going under.
What changed
It's unspectacular, and for me it's the whole point: during the day I do my job. And in the evening I'm back at the game instead of the order list.
Everything else happens — not by itself, but without me.