Stale Hobnobs and Half-Baked Ideas: How I Decide What to Build Next

There is a biscuit tin in my kitchen that has been in service since roughly 2019. It has never contained biscuits for longer than a fortnight, because I am the problem. What it actually holds is a rotating cast of tea bags, a broken ginger nut, and whichever chocolate digestives I have failed to eat quickly enough. It is, in other words, a perfect model for my side project list.

I keep a running note on my phone called Things What I Might Make. At any given moment it has between four and eleven entries. Some are a sentence long. One is currently just the word "timetable?" and a date. And for years I treated them all equally, which meant I started about a third of them, finished almost none, and spent a lot of evenings opening and closing the same two files.

So I made a rule. Not a productivity rule — I don't have the temperament for those — but a sorting rule, based on the tin.

Start with what's actually in the tin

First job is honesty. Empty the list out and look at it properly. Not the version of the list you'd show a collaborator, the real one. Mine had things on it I'd been carrying since 2023 out of a vague sense of obligation to a past version of myself who was, frankly, less busy and more optimistic.

If you cannot remember why something is on the list, that is data. It's a ginger nut at the bottom of the tin. Nobody is going to be upset if it goes.

Rule one: the rattle test

When you pick up a biscuit tin and shake it gently, you can hear what's in there. You get a sense of the shape of it before you open the lid.

I do the same with ideas. If a project can be described in one line that makes someone say "oh, go on then", it rattles. If I have to explain it twice, or reach for a phrase like "sort of a platform for", it's mush.

This is why the timetable idea keeps surviving. "A page that shows the next train from my local station, and nothing else" is one sentence and I can see the whole thing in my head. Compare that to a note I found from last spring which read: "something with photos and maps and maybe a blog?". That is not a biscuit. That is a handful of crumbs.

Rule two: the staleness date

Most biscuits have a date on the packet. Side projects should too, and it should be short.

My working number is three weekends. If the first version of a thing cannot exist after three weekends of evenings and odd hours, it's either too big or not interesting enough to carry me through the boring middle. Three weekends is not a deadline. It's a freshness check. If I'm still enthused at the end of it, I keep going. If I'm opening the file out of guilt rather than curiosity, it goes back in the tin and I note down why.

There's a lovely side effect here: knowing the first version is small means I get to the bit where it exists much sooner, and existing things are far easier to judge than imagined ones.

Rule three: broken biscuits are not heritage

This is the one that took me longest to learn, and it's the one I'd tattoo on my forearm if I were the sort of person who did that.

A half-finished project is not automatically valuable because you spent time on it. The 40% of a thing I built in 2022 has not become more precious with age. It has become a museum exhibit in my own head, and I've been charging myself admission.

So: if a broken project needs to be rebuilt from scratch anyway, it's not a project, it's a sketch. Write down what you learned in a sentence, close it, and move on. The learning was the value. The code was scaffolding.

Genuine heritage does exist, by the way — a handful of things I've made are still running and still used, and those get maintenance time. But that's a short list and it's easy to check. Everything else is compost.

Where the tin logic breaks

Two places, and I'd rather admit them up front than have someone in my replies do it for me.

First, it's rubbish at collaborations. The rattle test assumes I'm the only one rattling. If a friend is involved, enthusiasm isn't a private calculation anymore, and quietly binning something is a rotten way to treat a person's time.

Second, it's biased against slow, quiet work. Some of the best things on this site started as ideas that would have failed the three-weekend test — they needed six months of half an hour here and there, and they only made sense once they were nearly done. The tin rule rewards clarity and small scope. It punishes anything that has to grow into itself.

My workaround is inelegant: I keep a small shelf above the tin for projects I've decided to protect from the rules. Two at most. That's it. Anything else has to take its chances with the rattle.

Have a go, then tell me I'm wrong

If any of this is useful, the version you can do in ten minutes is this: open your list, write one line per project, and stick a W next to anything you could genuinely get working within three weekends. Then cross out everything you couldn't describe to a stranger without using the word "platform".

What's left is your tin. It'll be smaller than you expected, and the strange thing is that it won't feel like a loss. It'll feel like you've finally got room for the good ones.

And if you try it and it goes horribly, do let me know. I'm at the address on the contact page, and I'm always up for being told my biscuit-based reasoning is nonsense.