Reflections after 14 weeks, 550+ versions, and one seven-year-old co-designer
Get Floor Is Lava on Google Play
Floor Is Lava started as a seven-year-old talking into a phone about coloured platforms and a coin shop, and ended up a published Google Play game with real downloads, real ad revenue, and a whole system of bosses, modes and monetisation behind it. Between April 28 and the first week of August, it went through more than 550 versions: most nights after bedtime, in a garage, with an AI doing the typing while I did the deciding.
This isn’t a how-to. It’s what actually slowed things down, what turned out to be easier than expected, and what I wish someone had told me on day one: written for anyone thinking about building their own app with an AI collaborator rather than a computer science degree.
What was harder than it looked
Sign-in and billing bugs came back again and again
The single most recurring source of pain in this whole project wasn’t game design: it was authentication and purchases quietly falling out of sync with each other. Sign out, sign back in, and suddenly a premium account looks like a guest. Buy something, and the sync to the backend fails silently. This happened more than once, on more than one day, months apart, in slightly different shapes each time. If you’re building anything with accounts and payments, budget real time for this category of bug specifically; it’s not a one-and-done fix, it’s a class of problem that resurfaces as you add features around it.
Production builds are a different beast from dev builds
More than once, a build that worked perfectly in testing broke in production because the production file was missing a function that only got included in the full development version; extra logic like bundled change logs got compiled into a build that was never meant to carry it. The fix, eventually, was a firm rule: production builds are built as production builds from the start, not trimmed down from a dev version after the fact. Cutting corners between “what I test” and “what I ship” is exactly where bugs like to hide.
The platform’s process, not the code, sets your timeline
Writing the game was, in a lot of ways, the fast part. Getting it in front of real users was gated by Google Play’s own rules: closed testing requires twelve separate Google accounts to actually install the app, and a mandatory fourteen-day clock that runs regardless of whether those testers ever open it. That meant actively recruiting testers weeks before the game was “ready,” through friends, Facebook, and even getting a seven-year-old to hand out flyers at school. If you’re planning a launch date, plan backwards from platform review and testing requirements, not from when you expect the code to be done; they rarely line up.
Payments have more moving parts than one integration
Getting money to actually move required stitching together separate systems for separate platforms: Google Play Billing for the Android app, Paddle for anything sold on desktop, and AdMob layered on top for ad revenue. Each one has its own approval process, its own test mode, and its own way of quietly failing. Treat “monetisation” as three or four separate integration projects, not one line item.
What was easier than expected
Voice notes turned out to be a legitimate design tool
The entire original design document for Floor Is Lava was a kid talking out loud into a phone for a few minutes: platform colours, coin values, power-up costs, level-up rules. Run through Otter.ai for transcription and then into Claude, that recording became something close to a real game design document, and nearly every mechanic in it shipped in the final game. If you have a clear idea of what you want but don’t want to sit down and write a formal spec, just talking it through and transcribing it is a genuinely fast way to get from “idea” to “buildable list of features.”
A trusted, patient non-coder friend is an underrated test case
Watching someone who tried coding once, years ago, and gave up, react to the finished pipeline: AI handling design mockups, bulk data work, and full feature implementation from a spoken idea; was a good reminder of how much friction has actually been removed from building software. If you want an honest read on whether your product and your process make sense to an outsider, show it to someone who isn’t a developer and watch what surprises them.
Small polish passes compound faster than expected
None of the late additions: a rising lava-coloured progress meter, a rocket exhaust trail on a boss’s ship, screen shake on a boss’s entrance; were big features on their own. But stacked up over the last couple of weeks before launch, they were the difference between a game that technically worked and one that felt finished. It’s worth protecting time for this kind of pass specifically, separate from bug-fixing and separate from core feature work, because it tends to get squeezed out otherwise.
Things I didn’t know going in
- Being “approved” isn’t the same as being “found.” Google Play approval took less than a day. Getting the first organic download from a stranger took several more days after that, and it came from unpaid promotion, not from the approval itself. Approval is a gate, not an audience.
- Playable ads are worth building early, not late. A sixty-second playable version of the game: built the same night as launch, almost as an afterthought; turned out to be more immediately addictive than the full game in some ways, and is reportedly one of the highest-converting ad formats in mobile gaming. If you’re planning any paid promotion at all, build the playable ad alongside the game, not after it ships.
- “AI slop” comments will happen regardless of how the game was actually made. Public reaction to AI-assisted work can be dismissive by default, independent of the actual quality or the actual human input behind it: in this case, months of decisions and a genuine hand-drawn character design from a seven-year-old. Decide in advance how much that kind of comment is going to bother you, because it will show up.
- Tiny numbers are still real signal. Seventeen cents of ad revenue and one download from a stranger on the other side of the world aren’t meaningful money, but they’re proof the entire pipeline: build, publish, discover, install, monetise; actually works end to end. That’s worth treating as a milestone in its own right, separate from any revenue target.
If you’re about to start building an app
Treat authentication and payments as an ongoing category of risk, not a checkbox to tick once. Plan your launch timeline around platform review and testing windows, not around your own coding pace. Keep your production build genuinely separate from your development build from day one. Talk your idea out loud before you try to write it down. Show the unfinished thing to someone outside the project early. And build the sixty-second version of your game: the ad, the trailer, the pitch; at the same time as the real thing, not as an afterthought once it’s already shipped.
Reflections drawn from the full Floor Is Lava development diary, April 28: August 2026.
Diary Of A Mad Chaos is a daily diary written from March 1996 until today, of which individual books and book series have been created, namely “The Lost Years” an exploration of young, entwined love, the “Wubao In China (猎艳奇缘)” book series which provides an extensive comparative analysis of the cultural differences between Eastern and Western societies, and the book titled “Foreigner (华人)” an exploration of race relations in Australia.
