Play first, ship second: how side projects become product

A lot of what I know about building products I learned from things that were never meant to be products.

This site has a daily puzzle on it. I built a netball scoring app for my wife. I published a library of prompts for school staff and gave it away. None of those paid for anything. All of them changed how I build SGAF, which does.

Here is why I keep playing, and what transfers.

Play has no stakeholder

When I build for a customer there is always someone to disappoint. A deadline, a budget, a board that will see it on Thursday. That pressure is useful and it is also a cage. You build the thing you already know how to build, because the thing you do not know how to build might not land in time.

Play has none of that. Nobody asked for Locket. It is four gems, a reading that tells you how many are set and how many are loose, and a new seal at midnight. I made it because I wanted to, and because I wanted to find out whether I could ship something small, end to end, with no server and no account, that stays entirely on the player's device.

I found out. And the next time I needed a feature in SGAF that had to work without touching the database, I already knew how.

Discovery is cheaper when nothing depends on it

NetCall is a courtside netball app. I built it for my wife, who umpires netball. I am not the umpire, so I had to learn the job as she does it: prepare the match, score live, track the centre pass, share a clean result when the whistle goes.

The job happens standing up, in bad light, with the game refusing to stand still. That constraint drove every decision. Big targets. No menus mid-game. A native app, because the browser was never going to be fast enough with cold hands.

I did not set out to learn a method. But "start from the job someone is already doing, as they actually do it" is now how every SGAF feature begins. Boards were already doing governance. The record was papers, memory and whoever knew where the last pack lived. The product follows the job. I learned that courtside.

The free thing teaches you what is scarce

Free-SchoolAI is a library of copy-paste prompts for school staff, from early years to sixth form. Leaders, teachers, exams officers, cover. You copy the prompt, run it on a machine you control, and a person still owns the draft.

Giving it away taught me something I would not have learned by selling it. The wording was never the scarce thing. Anyone can write a prompt. What is scarce is the evidence to put into it, the name on the letter, and a model you are allowed to use.

Each prompt in the library carries a small flag. If the job can become a pupil, staff or legal record, the card says so, and tells you not to paste it into a public chat. That flag started as a courtesy. It became a principle in the business: no pupil, SEND or safeguarding data ever goes into an agent. The free project found the rule. The product inherited it.

What transfers, and what does not

What transfers is constraints. Play surfaces a constraint you did not know about, and the constraint becomes a rule in the real product. No server. Follow the job. Flag the record. Each of those arrived through something that did not matter, and each is now load-bearing.

What does not transfer is code. I have almost never lifted code from a side project into SGAF. The puzzle's code is for the puzzle. What moved was the understanding.

That matters because it changes what you optimise for in play. You are not building a prototype. You are building a situation in which you will notice something.

How I keep the two apart

Side projects get evenings, a repo each, and no customers. If one starts to acquire customers, it stops being a side project and gets the full treatment: the gates, the reviews, the release checks. NetCall crossed that line and is now a paid app with the discipline that implies. Locket has not, and I hope it never does.

I also give the agents side projects. One of them looks after the scoring app. It is a low-stakes place to find out how an agent behaves with a codebase before I trust it with the one that matters.

Why this is worth a post

The usual advice to founders is focus. Cut the side projects, pour everything into the one thing. I understand the advice and I have ignored it, and I think the reason is that the one thing is only as good as what I notice, and I notice more when I am playing.

Build something nobody asked for. Make it small enough to finish. Then watch what it teaches you about the thing people are paying for.