KJ’s Games
A live games site I’m building as a proper ‘ship things’ playground: two card games live with accounts + analytics/events, and a tower defence game currently cooking.
KJ’s Games · 2026 - present · Product owner, developer, and delivery lead
Goals
- Ship a real product and iterate in small, repeatable releases
- Instrument meaningful analytics/events so I’m improving based on behaviour, not vibes
- Build state-heavy game logic that stays readable and maintainable
- Keep it fun and sustainable (because I actually want to keep working on it)
Constraints
- Solo delivery with limited time windows
- Balance experimentation with maintainability (no ‘prototype forever’ debt)
- Analytics and release processes needed to stay lightweight and repeatable
- Staging and production required strict behaviour separation
Problem
I wanted a low-risk place to practise proper delivery under real conditions — not just ‘it works locally’. That meant real deployments, real routing, real analytics/events, accounts, and a codebase I can keep extending without it turning into a haunted house.
Approach
Phase 1: Platform + environment foundations - Set up a clean delivery flow through DigitalOcean App Platform and Cloudflare. - Implemented staging safety: noindex + tracking suppression.
Phase 2: Core app structure + routing - Established route and component patterns for incremental growth. - Put the basics in place so adding games doesn’t mean rewiring the whole app.
Phase 3: Accounts + persistence - Added accounts so gameplay can be tied to a user (not just a device). - Kept it practical: sign in, play, track.
Phase 4: Consent + analytics/events - Added GTM/GA4 behind consent checks. - Defined events around gameplay actions so I can spot friction and prioritise improvements.
Phase 5: Iteration loops + ‘keep it shippable’ discipline - Shipped in small increments with cleanup passes. - Used analytics signals + my own playtesting to shape the backlog.
Implementation highlights
- Two card games live with state-heavy interaction logic and edge-case handling
- Accounts-enabled experience so progress and usage can persist across sessions/devices
- Consent + environment gating so analytics behaves responsibly (and staging stays clean)
- Event tracking aligned to gameplay and engagement (the stuff that actually informs decisions)
- A repeatable release workflow that supports fast iteration without panic deploys
Challenges
- Keeping momentum without sacrificing code clarity (solo projects love to drift)
- Choosing where AI acceleration helps vs. where manual implementation is safer
- Keeping analytics useful without over-instrumenting everything
- Designing game logic that feels solid without it turning into spaghetti
Results
- A live platform with two playable card games and accounts support
- Higher confidence in end-to-end delivery: build → deploy → measure → iterate
- A practical analytics baseline for roadmap decisions based on behaviour
- A solid foundation for the tower defence game and future experiments
What I'd do next
- Expand the event taxonomy into a simple funnel + retention view
- Add lightweight release notes so changes are trackable over time
- Harden the game-state layer with more automated tests around edge cases
- Polish UX/accessibility pass across menus, modals, and gameplay controls
How AI helped
ChatGPT helped me keep the work in sensible slices (so it didn’t become a never-ending refactor) and sanity-check trade-offs like ‘ship now vs. clean it up first’. Codex was best for the heavy lifting and consistency: implementing repeatable patterns, doing cleanup passes, and helping me move faster without the project turning into a mess. AI made me quicker, not careless — the quality bar is still manual.