Behind the Scenes of Doodle Doo — What the Commits Won't Tell You
I wrote yesterday about how Doodle Doo started — the 10-second constraint, the rooster who roasts your art, the joy of drawing badly on purpose. But blog posts skip the messy parts. The parts where you're staring at API error logs at midnight, or realizing your AI model has developed a personality problem, or discovering that players will absolutely try to cheat at a drawing game and somehow that's the best thing that happened to the project.
This is the rest of the story.
The Weekend It Came Together
Doodle Doo started as a single evening of work. The entire API skeleton — game logic, database models, scoring system — landed in one push. By the end of the weekend, the drawing screens worked, the backend could analyze images, and the deploy pipeline was wired up. Three days from nothing to something playable.
Then the repo went quiet for a month.
Not because work stopped. Because I was building without committing — testing, breaking, fixing, iterating — and only pushing when the thing felt coherent enough to version. When the code re-emerged, it had achievements, crash reporting, and a UI that actually looked like a game. The git log shows a launch. It doesn't show the late nights where nothing worked.
This is solo dev reality: the commit history is a highlight reel of its own.
The Beta Arrives
The day the game hit real players, everything started cracking.
The cheating problem showed up almost immediately. Players realized they could just write the word instead of drawing it — and honestly, that's on me for not anticipating it. The fix wasn't just detection. I wrote Doodle a special cheating response where he takes the offense personally, delivering a dramatic, highly offended monologue about how the player has insulted his "refined sensibilities" as a PhD in Art History. The cheating detection became one of the most shared features in the game. Players who get caught love showing off the rooster's reaction.
The rooster had another problem: he got repetitive. Across a game session of six, twelve, or eighteen rounds, he'd recycle the same burns. The fix required teaching Doodle to remember what he'd already said. Before generating each new roast, the backend fetches every prior comment from the same game session and appends a "do NOT repeat these" instruction to the prompt. The rooster's memory is more complex than it looks — it joins across three database tables just to make sure he doesn't reuse the same joke twice.
The subscription pipeline broke on day one. Four commits in half an hour, each one a slightly different theory about why RevenueCat wasn't detecting entitlements properly. The fourth theory was right. Every mobile developer has a payments afternoon like this. Mine was the day after beta launched.
The Model That Kept Disappearing
The hardest technical problem in Doodle Doo wasn't the game logic. It was the AI model that powered the whole thing.
Midway through development, Google released a preview version of Gemini Flash that was faster and more accurate than the stable release. I switched immediately — better roasts, quicker response times, happier players. But there was a catch: it was a preview model, and preview models don't come with availability guarantees.
The model would just… vanish. API calls would hang. Requests would time out. Sometimes it'd be down for minutes. Sometimes hours. There was no status page, no SLA, no warning. You'd deploy an update, go to bed, and wake up to a game that couldn't analyze anyone's drawings.
The fix was the fallback system. Anytime the preview model returns an error or times out, the backend silently retries with the stable Gemini model. Players never see the switch happen — their drawing just gets analyzed a fraction of a second slower. The fallback code is maybe the least glamorous thing in the repo, but it's the reason Doodle Doo doesn't go down when Google's preview infrastructure has a bad day.
This is what building on AI looks like in practice: you're not just integrating an API. You're building a safety net under someone else's experimental infrastructure.
The Problems You Can't Predict
Some bugs are obvious. The subscription pipeline breaking, the cheating detection being needed — those make sense in hindsight. Others only surface when you play the game enough.
The rooster's frame-by-frame replay accuracy started slipping. I traced it back to the model change — the preview model was interpreting drawings differently than the stable one was, and the frame guesses were slightly off. The fix involved a week of tuning: stripping humour from the frame guess prompts to focus purely on accuracy, removing duplicate checks, adjusting the recognition thresholds. At one point I switched back to the old prompting strategy entirely because it just worked better.
The profanity filter broke silently. New usernames were timing out during registration because the moderation check was using the wrong model — a one-line change nobody would notice unless they tried to sign up. Fixed in thirty seconds after an hour of debugging.
The review screen had a loading problem that looked like a UI issue but was actually a database problem. Before showing the game, the app was waiting on streak data, user stats, and gallery information — all before it could send the first drawing to the AI for analysis. The fix inverted the order: fire off the AI call immediately, then load the extra data while the model is thinking. The player sees their drawing start analyzing faster, and the database queries run in parallel with the AI instead of before it. Two systems that don't depend on each other shouldn't have to wait for each other.
The Endless Polish
The back half of the build was less exciting to describe but more important to ship. Account deletion. Back navigation on iOS. Share cards with the drawing subject included. Offer code redemption. The Judges Roost button on the final score screen. These are features nobody puts in a pitch deck, but every one of them would generate a support email if they were missing.
The results screen got more attention than any other view in the app. More than the home screen, more than the gallery, more than the drawing canvas itself. Players don't remember the moment they drew something. They remember what Doodle said about it. Every time I thought I was done with the results screen, another edge case appeared — a button too small on certain devices, a navigation path that didn't handle the back gesture properly, a share flow that needed one more tweak.
The backend also had to grow up. What started on a simple hosting service eventually moved to proper cloud infrastructure with Docker builds, dedicated logging, and database connection pooling. Rate limiting appeared once enough players were hitting the API simultaneously. A priority request fallback handled the spikes. These are the changes you make when the game stops being a prototype and starts being a product with actual traffic.
What the Build Taught Me
If you're making an AI-powered game, here's what three months of shipping taught me:
Preview models are a trap with an escape hatch. The bleeding-edge model will always be tempting — faster, smarter, more capable. But if it doesn't have an SLA, you need a fallback. Not a nice-to-have. A hard requirement. The day you skip it is the day the model goes dark.
Cheating detection is content design. I built the anti-cheat system to protect the game. Players turned it into the most viral feature in the app. What was supposed to be a security measure became a core part of Doodle's personality. Sometimes the thing you build to stop bad behaviour becomes the reason people stick around.
The AI call is the critical path. Every millisecond you spend loading data before the AI starts thinking is a millisecond the player is staring at a spinner. Move the AI call as early as possible in the request lifecycle. Everything else can load in parallel.
Results screen > everything else. The drawing is three seconds. The gallery is a scroll. The home screen is a menu. The results screen is where the game actually happens — the rooster's verdict, the frame-by-frame replay, the share button. I spent more time on that one view than any other screen, and it shows in how players use the app.
Three months from first commit to a shipped game with a personality. The tools are getting better. But the hard parts — the model roulette, the cheating arms race, the endless polish — those don't go away just because AI is doing the heavy lifting.
— Chad, Bunnyhug Studios 🐰