Call the Cat: Delivery — launch devlog
TL;DR: I deleted Google login, cloud save, and payment, convinced our web-based tech stack made them impossible. What actually got deleted was the code path that called them — the real bug was still there, and I’d just piled a wrong decision on top of it.
I decided a feature couldn’t work with our stack, told the AI to rip it out — and had to undo it a day later.
After days of being stuck, I concluded “this is just how web apps are”
Google login and Google payment kept failing in the internal test build. I re-checked console settings, re-verified auth credentials, and none of it ever finished on a real device. After a few days I landed on a conclusion: “our game is a web app wrapped for Android — Google login, cloud save, and Google payment must simply not work with this architecture.”
So I told the AI to remove all three. It deleted the Google account screen, turned off cloud save, and hid the payment card so only the app-store-specific payment path showed. One commit made every Google-related execution path disappear from the code.
Removing a feature as “impossible,” then confirming it works and undoing the removal.
A day later, the conclusion stopped making sense
Something didn’t add up on reflection. I’ve shipped four games. Two of them — one built in Unity, one in GameMaker — use the same Google account’s Google features, and they work fine. Only this web-based game didn’t.
If “impossible because it’s a web app” were true, it couldn’t explain features working in games built a different way, on the same Google account. So I gave the AI a different instruction: “find the missing implementation. Don’t assume it’s impossible just because it’s web-based.”
What got deleted wasn’t the feature — it was the path to it
Recovering the code showed what actually happened. The commit that changed direction had deliberately cut the execution path that reaches Google’s features. The line that starts the login SDK on app launch was deleted. The function that checks whether cloud save is available had been changed to always return “no.” The code that calls price lookup, purchase, and restore for payment was never invoked anymore.
Meanwhile, the native connector components, the Google library dependencies, the permissions in the config file, and the products registered in the console were all still there, untouched. The parts were all present — only the lines that called those parts were missing.
In other words, the original problem (login and payment never finishing on a real device) and the conclusion I reached (“impossible because it’s web-based”) were two separate things. The original problem was still unsolved. I had simply added a “let’s delete it” decision on top of it.
The libraries, permissions, and console products all stayed. Only the code path that called them was cut.
What actually saved us was a backup branch
Before starting the recovery work, the AI had already done one thing right: it had pushed the removed-state code to a separate backup branch in the repository first. The recovery work itself happened on yet another new branch.
That meant there was a safety net — if the recovery got tangled, we could always go back to the removed state. If we had committed the removal and kept building on top of it, undoing it would have been far more dangerous.
What to copy — three checks before you delete a feature entirely
Before ripping a feature out completely, confirm these three things first:
| Check | Why |
|---|---|
| Does this feature work in a different environment or a different project? | If it does, it’s not “impossible in principle” — it’s an implementation gap in this project |
| Is the symptom you’re seeing actually caused by this feature, or is there a separate root cause underneath it? | Deleting without finding the real cause leaves the real cause exactly where it was |
| Did you push the current state to a backup branch before deleting? | You need somewhere to go back to if the recovery doesn’t go cleanly |
If the answer to any of these is “no,” it’s not time to delete yet.
Three checks before ripping a feature out entirely.
One line to hand the AI before asking it to delete something
“Before you remove this feature, push the current state to a backup branch. And give me evidence for whether this is genuinely impossible with our approach, or just an incomplete implementation. Don’t delete it on a feeling that it ‘probably won’t work.’”
This line blocks exactly one thing: deleting code on a hunch. This time I gave that hunch a full day of deletion work, and undoing it the next day took even more work than the deletion had.
Where this leaves things
It’s easy to land on “this must just be impossible” after a few unproductive days. But before acting on that conclusion, check whether it works somewhere else first. In our case, the same Google features worked in other games we’d shipped with a different tech stack — and that was the evidence that “impossible because it’s web-based” was wrong.
What got deleted wasn’t the feature — it was the code path that called it. The original problem never moved. What’s confirmed so far is the removal commit, the recovery commit, and the backup branch. Whether the restored login and payment actually complete on a real device is still something I have to check.
Solo dev of Call the Cat, shipped after 178 days
on Google Play
and Steam.
Now building Call the Cat: Delivery and Call the Cat: Galaxy, in public.
Leave a Reply