From daily releases to weekly

TL;DR: Almost every project hits a point where it stops being a feature factory and turns into steady, tested releases, and it tends to land the week real users show up. For Inselnova that was mid-April, when a few hundred players arrived at once. I went from shipping a new version most days to about one a week, and the rate of new bugs I logged dropped right after. It’s the normal move from building fast in an empty world to building carefully in a full one, and it’s worth seeing coming if you’re going to build a game or a web app yourself.

Early on, a feature factory is the right mode

The first version went out on the 23rd of February. Since then I’ve shipped 95 of them, plus a steady run of small hotfixes on top. At the busiest, in early March, that was as many as thirteen new versions in a single week. Each release was small, usually around a dozen changes, so I could push something, watch it, then fix or build on it within hours. With almost no one in the world yet, that’s exactly the mode you want. You build, you ship, you see it live, you move on.

That mode is built for an empty world. The economics change the moment the world isn’t empty.

Then a few hundred of you arrived

The week of the 13th of April, 322 new players signed up. That’s the single biggest week the game has had. Up to that point most of the testing was me and a handful of regulars clicking around. Real players, playing for real and in numbers, find things that solo testing never will. They use the game in ways I never thought to test.

Reports climbed straight away. In the busiest weeks of April players were sending me close to forty reports a week, and the rate of new bugs I was logging climbed right alongside the new arrivals. A feature factory runs on a quiet bet: every quick release is a small wager that you won’t break something. In an empty world that bet costs nothing. With a few hundred people living in the world, a broken release gets noticed in minutes and lands on someone mid-game, so the same bet turns expensive fast. People told me, plainly, in their reports. That spike is the signal to change modes.

New bugs, before and after the players arrived

This is the number of new bugs I logged each week, from April through to now.

The two tallest bars sit right on top of the player surge, and then the number comes down and stays down. New bugs are down to one or two a week now, and reports from players have settled to a handful a week. Across the whole run I’ve fixed 104 bugs and there are 7 still open.

The shift to steady, tested releases

The second mode is the opposite of the first. Ship less often, test more before each release, and make each one solid. I’d rather put out one version a week that I’ve sat and checked than five quick ones that each carry a decent chance of catching someone in the middle of their game. Through May and into June the pace settled to about a release a week, and the bug numbers followed it down. It held even when a fresh wave of players turned up in mid-June. This is the part most projects reach eventually, in games and in web software both: the feature factory did its job, and steady, tested delivery takes over.

Shipping less often doesn’t mean working less. This is every day I committed code from launch to now, one square per day.

The squares stay filled right through, even where the version chart thins out. The work didn’t slow, the shipping did. More of it now goes into testing and groundwork before anything reaches you.

Where your messages actually go

In this mode the player reports are a lot of what I work from. Every request a player sends lands in one place first, and I read all of them. Then I usually sit with one for a few days before deciding what to do with it. A lot of the time a request doesn’t become its own change at all. It gets folded into something bigger I was already planning, because once you read enough of them you start to see the same need behind five different suggestions. And sometimes I know a request matters but I’m sitting on it because I haven’t worked out how to fit it into the world and the lore yet.

About a third of the people who’ve ever reported something have since moved on from the game. The reports didn’t leave with them. Most of what they flagged is fixed and live, and some of it shaped things they never got to see.

Groundwork comes first

More than a quarter of everything on my board is plumbing, the under-the-hood work you never see directly.

Those tags are rough. They’re hand-applied and they overlap, a card can carry more than one, and none of them say whether a card took ten minutes or three days. The shape still holds: the biggest single slice is plumbing, not features. When releases space out, it’s usually because I’m doing that kind of work first. I’ve got a bigger feature in mind, and to get there cleanly I have to change other parts of the game before it’ll fit. I could bolt the new thing on and ship it sooner, but that’s the bill a feature factory quietly runs up: messy code that breaks in five new ways later. A quiet week is usually me laying track for something bigger.

Keeping it boring on purpose

Steady releases only stay affordable for one person if the day-to-day running is boring, so I keep it boring on purpose. I like boring. I used to run a software team where the devops group was four people, and we were still in enough of a mess that we needed more. It was a permanent cost centre, a steady drain that produced nothing a user could see. These days I build the systems to need as little of that as possible, and I treat picking the right web host as part of the actual work, not an afterthought. I’ll happily pay a small premium for a host that saves me time, because the alternative is time and money pulled away from the game.

Most people don’t care what the stack is. A thin slice do, and that’s fair enough, but the rest just want a good game to spend their time on. So the day-to-day running of it is deliberately dull. I watch memory and processor load on the web server and the database, and when something spikes I read the logs. Nine times out of ten it’s a missing database index. I add the index, the spike goes away, and that’s the whole drama.

Where it’s landed

Most of the foundation is built now. The game does what I set out to make it do, the big systems are in, and what’s left leans more towards care than construction. So I ship less often, check more before I do, and the bug count shows it.

If you build a game or a web app, you’ll meet the same two modes. A feature factory is right while the world is empty and you’re still finding out what the thing even is. Steady, tested delivery is right once people are living in it. The week your reports spike is the week to switch, and it’s a good week to reach, because it means people finally showed up.