Pixel Pals
A cozy iOS pet game — and an honest story about pivoting twice to find the core loop.
- Role
- Product Owner, Game Designer & iOS Developer (solo)
- Team
- Solo, AI-assisted (Claude Code agents)
- Context
- Personal project, not shipped
- Tools
- Swift, SwiftUI, SpriteKit, XCTest, GPT image generation
Pixel Pals started as a cozy Japanese spirit-collector idle game. Fourteen sprints, two pivots and 230+ automated tests later, I wrote a 'concept reset': we had built lots of UI, but never the core loop that makes a pet game work. So I restarted with a locked, one-pet MVP and a clear scope framework. Neither version has shipped yet — this case study is about the product decisions.
Version 1: a cozy collector
The first concept: Japanese yokai spirits visit your traditional house. You earn coins while away, invite spirits, renovate the room and fill a collection.
Built in sprints: offline earnings with a cap, rarities, a collection dex, treats and hunger, achievements, a naming ceremony and a memory journal.
Pivot 1: from collecting to caring
Collecting got stale quickly. I wrote a pivot document towards Tamagotchi-style care — and rethought monetisation with it: no gacha, no pay-to-win, evolution always reachable for free, because the cozy-game audience rejects aggressive mechanics.
Scope cuts along the way
- A 15-item decoration system with set bonuses was replaced by a five-stage room renovation — less content to produce, a clearer sense of progress.
- The premium shop was cut down to two items.
Pivot 2: the concept reset
After 14 sprints I stopped and wrote down an uncomfortable truth: lots of UI shipped, but the core loop was never implemented. I went back to why the original 1996 Tamagotchi worked and placed the game deliberately on a spectrum from stakes to stress: aging you can't stop, but no punitive death; cleaning that rewards, never punishes; no "welcome back" pile of chores.
The restart: one pet, locked scope
The successor, Pixel Pal, starts from a clean slate with a locked MVP: one cat, five life stages, five stats, one care loop. Every new idea has to pass four questions:
- Does it strengthen the core loop?
- Does it need new art?
- Does it need a backend?
- Would a five-minute player notice it's missing?
A phased roadmap with exit criteria ("an internal tester can play seven days without a game-breaker"), a risk table (iOS background limits, sprite consistency, App Store review of a death mechanic) and a premium price model — because free-to-play breaks the nostalgia.
How I worked
- A sprint changelog with test counts for every sprint; the game-design document as the single source of truth — tests check its numbers.
- A team of specialised AI agents (game designer, iOS developer, QA, monetisation) with a product-manager agent as arbiter of scope disputes.
What I learned
The most valuable document in the project is the one admitting I'd built the wrong thing. Writing it early would have saved weeks — and that's the habit I take into every product: name the core loop first, then defend it.