← Dev Log
Get people in, read the data, change one thing, repeat. The loop behind five onboarding rebuilds.

Get people in, read the data, change one thing, repeat. The loop behind five onboarding rebuilds.

browser strategy gamefree to play strategy game browserisland strategy gamegame onboardingproduct development

TL;DR: I’d never built a game before, so I didn’t start with a plan, I started with a loop. Get people in, read the data, work out what’s wrong, change one thing, get more people in. I’ve run that loop on the onboarding five times now. Each version was an experiment off the back of real data, not a tidy roadmap, and I didn’t widen the marketing until the thing I was sending people to actually worked.

The loop

I didn’t do competitor research. This started as a hobby, so I had a guess from playing the original for years and not much else. The only way to find out if a guess is any good is to put it in front of people and watch what they actually do.

So that became the loop. Get people in, read the data, understand it, think about it, make a change, get people in again. I’ve never shipped a game, which means I don’t know what I don’t know. The loop is how I work toward knowing. None of this is specific to games either, it’s just product development with the game as the thing being built.

Everything is an experiment

I got this framing from a book called Running Lean. Treat every change as an experiment, not a fix. An experiment can’t fail, it only returns data. Run ten and one of them will probably land. The trap is running five, watching all five flop, and deciding the thing doesn’t work. It does, you just haven’t found the version that does yet, so you keep going.

That’s how I think about the onboarding rebuilds below. Each one was a bet. Some worked, some didn’t, and the ones that didn’t still told me where to look next.

The shop

It helps to picture the whole thing as a shop. It’s a sales funnel really, the same one any product has, but a shop is easier to hold in your head. Six places a player can fall out, worth keeping separate:

  1. Can people find the shop? Whether you show up where players look.
  2. Do they come in? The front page through to registering.
  3. Do they look at the products? The onboarding.
  4. Do they buy anything? Actually playing once onboarding ends.
  5. Do they come back later that day? Sessions per day.
  6. Do they come back tomorrow? The next-day return.

You can only really work one of these at a time, and there’s no sense dragging more people toward step 1 while they’re falling out at step 3. That’s the whole discipline.

Don’t widen the top until the middle works

The first time round I targeted tightly on purpose. I went on Reddit and picked people by hand, messaging individuals who’d mentioned the original Inselkampf, and posted in a couple of small subreddits. I stayed away from the big ones. Those are close to a one-shot, and I wasn’t going to spend them on a game that wasn’t ready.

They came in, and the data was mostly bad. People didn’t convert into the game properly, and the feedback was that they “didn’t get it.” I thought I had exactly the right audience, players who already loved the original, so that stung. It left two possibilities. Either mine looked different enough from the original that it didn’t feel familiar, or the genre died for a reason and it isn’t really coming back. I bet on the first, and rebuilt.

Running the loop on onboarding

Every pass had the same shape. Pull the data, usually with an AI agent reading the production database, find where people dropped, put something basic in by hand, test it, then go back out to another small subreddit and a few more individual messages to get the next batch. I never pushed for more reach between versions. That would just be burning opportunity on a funnel I already knew was leaking.

Five versions came out of that, measured from April when the analytics went in. “Finished” below means a player earned the settlers’ seal, the durable marker that survived every rebuild underneath it.

VersionWhenSite, got inGot in, finishedSite to finished
v1, no tutoriallate Feb
v2, hacked togetherMar to Apr 1926%37%9.5%
v3, the tutorialApr 20 to May 319%66%12.7%
v4, guidance and copyMay 4 to Jun 913%72%9.4%
v5, guest accessJun 10 to 2438%56%21.3%

v1, no tutorial

Register, land on your island with a welcome message, and you’re on your own. No steering, no next step. This predates the analytics, so no numbers, only that it was the starting point.

v2, hacked together

Onboarding bolted onto the new achievements system. Popups, a welcome dialog with set progress, a fake bazaar listing so the market looked alive. The numbers aren’t a fair baseline: I was hand-recruiting players on Reddit one at a time, so this is good players meeting onboarding that barely held together.

v3, the tutorial

The Settlers’ Mark rails. A fixed sequence ending in the seal, the backend rebuilt to drive it. By v4 the tweaks started to feel like dirt I was rubbing into the main game, so this was the rehash that aligned onboarding with the first real achievement, so finishing it actually felt like something. Finishing jumped to 66%.

v4, guidance and copy

Polish. Advisor copy rewrite, better market guidance, gift claims. Finishing nudged to 72%, the best it got.

v5, guest access

A different experiment, on step 2 rather than step 3. Inselnova had a signup form between you and the map, like most browser strategy games, and this is where it came off. No form, you just start playing.

What each experiment actually moved

  • Rebuilding the onboarding lifted finishing from 37% to 66% to 72%. That’s step 3 working.
  • Taking the signup form out lifted getting in from 13% to 38%. That’s step 2, a separate door.
  • End to end, visitor all the way to finished, guest access roughly doubled the best version before it, 21.3% against 9 to 13%. A lower completion rate on a much wider top still comes out ahead.
  • The people who finish play about as long whether they registered or came in as a guest, around 12 to 13 minutes on day one. Removing the friction widened the top without watering down the players who stick.

To work on the front of the shop, I moved the shop front out

Steps 1 to 3 are mostly the website, not the game, and I kept needing to change it. The catch was that the frontend was the game, the same code, so every marketing tweak risked breaking the thing people were playing. I didn’t want that risk hanging over every change. So I split the frontend into its own repo.

Not a frontend-named one. A marketing repo, where the site sits next to the docs, screenshots, videos and copy, with its own AI setup for the marketing work. That’s a normal move when you’re building something, separating the part you experiment on from the part that has to keep running.

The next experiment

The shop tells me where to work next. Three boxes:

  • Step 1, getting found. Posting around small sites and subreddits is pulling people in. Working.
  • Step 2, front page to getting in. Guest access sorted the front gate. Working.
  • Step 3, the tutorial. This is where people drop, and more of them since guest access, which I half expected.

And it isn’t only the data. I’ve had genuinely useful comments from players about where they got lost, and they point the same way.

So the next one is a big experiment: the tutorial itself. Guest access only removed the form, it never touched the guidance or the copy, so the teaching is still the old version sitting behind a much wider door. The target isn’t turning guests into registered accounts, and it isn’t next-day return, the D1 number. It’s earlier than both. Get more of the people who arrive through the tutorial and into the actual game loop, so they understand how the game works sooner and decide it’s worth their time. Finishing on guest traffic is at 56% right now, and I want it back above 70%, where it sat before the doors opened, this time on the harder audience.

I still don’t know what I don’t know about making a game. The loop is just how I keep finding out, one step of the shop at a time.