Behind the Scenes of Infinite Scribe — The Six-Week Sprint
Yesterday I wrote about how Infinite Scribe started — the 2025 prototype, the Antigravity pivot, the New Year's resolution. But origin stories are clean. They skip the messy middle. Today I want to talk about what the actual build looked like: about six weeks, two repos, one developer, and a lot of late nights.
The Sprint Out of the Gate
The first line of code landed December 30, 2025. I was building both the mobile app and the backend simultaneously — React Native on one side, Python on the other. On New Year's Day, while most people were sleeping off champagne, I shipped the character memory system. The resolution wasn't a note in a journal. I was already three days in.
January 2nd was the first real grind. Character generation, inventory tracking, image prompts, database design, chapter persistence — all in one marathon session. The kind of day where you look up and realize you haven't eaten since breakfast.
January as a whole was a blur. By the end of the month the game had character creation, chapter progression, inventory, image generation, and the core odds system humming. The AI wasn't just writing paragraphs — it was running a full RPG engine under the hood.
The Gravity of a Good Game Loop
Some parts of the codebase just attract work. The story generation pipeline — the service that orchestrates every chapter, every dice roll, every scene transition — got more attention than everything else combined. The AI service layer right behind it. Those two systems are the heart of Infinite Scribe, and they demanded constant iteration.
On the mobile side, the main game screen absorbed half the development effort. The story list, the character creation flow, the ink store — everything else was supporting cast. The main stage got the rehearsals.
This is the quiet truth of software: the hardest problems cluster in a handful of places. Everything else is good enough after two or three passes.
The Week Audio Took Over
Voice narration wasn't in the original plan. Then I prototyped it and couldn't un-hear it — an AI Dungeon Master that actually reads your story out loud changes the entire feel of the game.
What started as a quick experiment ballooned into a feature that consumed early February. A play/pause toggle — obvious in hindsight, devastating to forget. Saving generated audio files without blowing up storage. Handling chapter endings gracefully — the AI doesn't know when a chapter is "done." Spacing between paragraphs so the narration doesn't sound like a wall of sound. Voice selection for different story tones.
Every one of these was a problem discovered by playing the game with audio on. You can't spec silence gaps in a design doc. You trip over them at 11 PM when the AI reads three paragraphs as one breathless sentence and you go "oh. right."
The Problems Nobody Plans
Some of my favourite moments from the build came from problems you can't predict:
Google Sign-In Hell. I spent the better part of New Year's Eve fighting OAuth. Every mobile developer has a "still trying to fix google sign in" night. Mine happened to be the night before the year the game would ship.
The "Practically Guaranteed" Problem. The odds system originally labeled the best outcome "Guaranteed." But there's always a dice roll — a 1-in-100 chance of failure on a d100. Calling it "Guaranteed" felt like a lie. One small change switched it to "Practically Guaranteed." Ten seconds of typing. But it took a playtester calling me out to realize it needed changing.
The Ink Flow Tuning. The economy started with a fixed amount of free Ink. Players burned through it faster than expected. The Ink store existed, but people didn't know where to find it. Two adjustments — bumping the free Ink amount, then adding a nudge that points low-Ink players toward the store — fixed the entire onboarding flow. These are the changes you can't make on day one because you don't have players yet.
Moving Day
The core game was built in that six-week sprint. After that came the long tail — the tweaks, the polish, the reactions to players. Sometime in March, the infrastructure caught up: private networking, proper logging, a full deployment pipeline. What started on a simple hosting service was now running on serious cloud infrastructure.
Not long after, I was optimizing database connection pools — the kind of tuning you do when you have enough traffic to need it.
What Six Weeks Actually Feels Like
If you're building something, here's what I learned from living inside this project:
The hardest feature isn't what you expect. I thought the AI story generation would dominate the build. It did — but audio narration was a close second, and monetization crept up across dozens of small changes I never planned. You discover what's hard by building it.
Solo dev notes are notes to your future self. Half my work logs are useless to anyone but me, because nobody else was reading them. "Various changes" was sometimes the day I rewrote the entire character memory system. That's fine. But it's funny to look back and realize how much happened under the least descriptive labels.
The gap between prototype and product is about reactions. Early on, you're building systems. Later, you're reacting to players — fixing the ink flow, tweaking labels, adding the store prompt. The shift from "does it work?" to "does it feel right?" happened somewhere in February, and I didn't notice it happening. I just looked up one day and realized I wasn't building a prototype anymore.
Six weeks from scratch to a playable AI RPG with voice narration. That's fast for any project. For a solo dev, it's absurd. The tools are getting better.
— Chad, Bunnyhug Studios 🐰