"Live-ops" is a word that arrives from free-to-play mobile with a lot of baggage attached: event calendars, battle passes, a content team, a monetisation analyst, a daily stand-up about yesterday's revenue. If that's the definition, a two-person puzzle studio has no business doing live-ops at all.
There's a smaller definition that's genuinely useful. Live-ops is the ability to change the game without shipping a build. That's it. Everything else — events, seasons, experiments, offers — is something you can only do because you have that ability. Build the ability first and the rest becomes optional.
Why the build-free change matters so much on iOS
App review takes as long as it takes. Even when it's fast, the round trip from "we found a problem" to "the fix is on most players' devices" is days, because it includes review time plus however long it takes users to update. For a bug you can live with, fine. For a difficulty spike that's costing you every new player, that delay is the whole ball game.
Remote configuration collapses that. A value the app reads at launch — or refreshes periodically — means the fix ships in minutes, to everyone, without Apple's involvement. That is the single highest-value piece of live-ops infrastructure a small studio can have, and it's the one to build first.
What to put behind remote config
Not everything. Every remotely-configured value is a value that can be wrong in production, and a codebase where anything might change at runtime is hard to reason about. A useful shortlist for a puzzle game:
- Difficulty and pacing constants. How many hints a player starts with, how quickly difficulty ramps, which level introduces which mechanic.
- Onboarding flow flags. Whether the tutorial is shown, skippable, or split across sessions.
- Feature flags for anything new. Every new feature ships behind a flag that defaults to off.
- Prompt timing. When the rating request appears, when a reminder fires.
- Ad frequency and placement, if you run ads.
- A message channel. The ability to show a short, dismissible notice in-app is invaluable the day something breaks.
What stays out: anything that changes core rules mid-session, anything a player has already paid for, and anything whose failure mode is an unplayable game.
Always ship a sane default
The most common live-ops disaster at small studios is an app that can't start because the config fetch failed. Every remote value must have a compiled-in default, the app must work perfectly offline, and the fetch must be non-blocking. Treat remote config as an override applied when available, never as a dependency.
Roll out slowly, on purpose
The point of instant change is instant change — including instant breakage. So the second piece of infrastructure is staged rollout: apply a config change to a small percentage of users, watch, then widen.
A workable pattern for a small studio: 5% for a day, 25% for a day, then everyone. Watch crash rate and the one metric the change was supposed to move. If either goes the wrong way, revert — and reverting must be a single action you've practised, not something you figure out under pressure.
Write down, before each change, what you expect to happen and what would make you roll back. This takes two minutes and it's the difference between a decision and a rationalisation.
Experiments: yes, but later and fewer
Once remote config exists, A/B testing is a short step away, and it's tempting to start testing everything. Two reasons to be restrained.
First, statistics. At indie install volumes, most tests will never reach a conclusion. A test that needs thousands of users per arm to detect a realistic effect will run for months at a few hundred installs a day, during which you'll want to change other things and contaminate it. Before running a test, estimate honestly how long it needs. If the answer is "longer than I'll wait", don't run it — just make the change you think is right and watch the retention curve.
Second, opportunity cost. A/B testing optimises within a design. Small studios usually have much larger gains available from fixing something obviously broken. Test when the obvious work is done, not instead of it.
When you do test: one variable, a pre-registered success metric, a fixed end date, and sticky assignment so a player doesn't flip between arms across sessions.
Content cadence a solo dev can sustain
The other half of live-ops is giving returning players something new. The trap is promising a cadence you can't hold — a weekly event calendar is a commitment to produce content every week forever, and the week you miss is more damaging than never having started.
Sustainable options for a puzzle game, roughly in order of cost:
- A daily puzzle. Generated, not authored. Zero ongoing content cost and it's the most reliable return driver in the genre.
- Themed puzzle packs. Batched — build six at once, release monthly, and you've bought half a year.
- Seasonal cosmetics. A palette or background swap driven entirely by remote config. Cheap, visible, and requires no build.
- Time-limited challenges. Same generator, different constraints, scheduled remotely.
Note that all four are things a generator produces or a config value switches. That's deliberate. Content that requires you personally to make something new each week is content that ends when you get busy.
Notifications: the tool most likely to backfire
Push notifications are part of live-ops and they're where small studios most often trade long-term goodwill for a short-term number. A notification that says something specific and useful — your daily puzzle is ready, the streak you built is about to lapse — is welcome. A generic "we miss you" is why people turn notifications off permanently, and you only get to lose that permission once.
Ask for the permission late, after the player has had a good experience, and explain what you'll use it for. Send less than you think you should.
The order to build it in
- Remote config with compiled-in defaults and offline safety.
- Feature flags on everything new, defaulting to off.
- Staged rollout and a practised one-click revert.
- A daily puzzle or equivalent zero-cost recurring content.
- An in-app message channel for when something goes wrong.
- Only then: experiments, seasons, offers.
Stop after step five if you want to. That's a complete, sustainable live-ops setup for a small studio, and it does the thing that actually matters — it means a problem discovered on Tuesday is fixed on Tuesday.