Real streets, playable stories: building City Fable solo, with AI as the execution layer
Summary
Live site:
Role: Solo Founder, Product Designer & Builder
City Fable is a self-guided GPS mystery game platform: buy a licence, get a code, and walk a real city street as your phone unlocks the next chapter of an original mystery. I’m the solo founder, product designer, and builder: every architecture decision, every screen, every line of shipped code passed through me, with AI handling most of the execution.
This project was as much a test of a delivery model as it was a product launch. Could one person, using full AI orchestration paired with human judgement, take a consumer product from a blank page to a live, paying release, backend, frontend, payments, and content included, without a team behind it?
I’m a UX-led product builder first, and that carried through here. My working bias is that a good product is a highly usable one, so usability and accessibility (WCAG) checks were built into the process from the design stage, not bolted on at the end.
Product challenge
Two challenges stacked on top of each other here.
The delivery challenge: build a production-grade, revenue-generating product end to end, solo, without slowing down to the pace a small team would normally need.
The product challenge underneath it: turn a real city street into a self-paced, playable story experience with no live guide, no fixed time slot, and no per-trail production budget that only scales with a big team.
The build model
| Goal | Response |
|---|---|
| Full ownership of product direction | One person carrying product, design, and technical decisions across the whole build |
| Usability as a non-negotiable | UX-led design decisions throughout, with WCAG/accessibility checks built into the design and prototyping stage, not a final check |
| Ship a real product, not a prototype | Production-grade stack: modern frontend framework, relational database, secure payments, transactional email |
| Move at AI speed without losing quality | AI handled architecture drafting, code, and asset generation; I made the calls on what shipped |
| Validate before scaling | Launched one trail, The Hungry Mile in Sydney, before committing to the national catalogue |
AI tool stack
| Tool | How I used it |
|---|---|
| Large language models | Shaping the game mechanic, licence model, and system architecture before any code was written |
| Large language models (design & prototyping) | Coordinating on user journeys, screen flows, screen design, and HTML prototypes; breaking the feature set into phased user stories for build |
| Agentic AI coding assistants | Primary and secondary build tools: end-to-end feature work, backend logic, and integration across the app |
| AI image generation tools | Generating city and story visual assets for each trail |
| Manual product & design judgement | Deciding what shipped, what got cut, and how the trail experience should feel from purchase to final clue |
Key point: AI orchestration carried the execution load. The product judgement, the pacing of the mystery, the trust signals needed on a real checkout flow, still had to come from a human.
Stack
- Frontend/Backend: Modern component-based JavaScript framework
- Database: Relational database
- Payments: Secure third-party payment processor
- Communications: Transactional email for instant code delivery
- Content: GPS-triggered story chapters built around an original mystery narrative
AI-assisted delivery process
Stage 1: Idea & architecture Define the product and licence model: self-guided play, one licence covering up to six players, GPS-unlocked story chapters. Use large language models to plan the system architecture and data model before any design or code work begins.
Stage 2: Design & prototyping Coordinate with large language models to map the user journey and screen flow, design the screens, and produce clickable HTML prototypes. Usability and WCAG/accessibility checks are run against the screen designs and prototypes at this stage, not left until after build. In this same stage, the LLM plans the full feature set and sections it into user stories, phased for delivery across the build.
Stage 3: Build Work through the phased user stories with agentic AI coding assistants: backend logic, frontend, payments integration, transactional email. Generate visual and story assets with AI image generation tools alongside the build.
Stage 4: Test & launch Test the full path manually: purchase → code delivery → redemption → GPS unlock → story completion. Launch the first live trail in Sydney, then use it to validate the roadmap for Perth, Melbourne, Brisbane, Adelaide, and Canberra.
What I learned
- AI orchestration is strongest as an execution layer, not a decision-maker. Architecture, code, and assets moved fast once the product direction was already clear. The direction itself still had to come from me.
- Usability isn’t a phase, it’s a filter. Running WCAG and usability checks against the screen designs and prototypes in Stage 2, before a line of build code was written, meant accessibility shaped the product instead of being patched onto it later.
- A real payment flow changes the bar. Once actual money and a real checkout are involved, “good enough for a demo” isn’t good enough. Every screen from purchase to first clue needed to hold up on its own.
- Solo doesn’t mean small. Carrying product, design, and build end to end solo was only possible because AI closed the gap between decision and implementation, without giving up ownership of either.
Closing thought
City Fable is the proof case for this delivery model: one founder, full AI orchestration, and a shipped, paying product, with human judgement still doing the part AI can’t.