Solo Dev Log · Part 3 of building and shipping Call the Cat in 178 days · Read the whole build log →
Fifteen days in, I had a prototype that moved.
The character walked.
It jumped.
The screen transitioned between rooms.
Watching it run made me think
shipping was right around the corner.
It wasn’t.
Getting from that prototype to an actual beta
took a lot longer than another fifteen days.
Here is what filled the gap.
What 15 days bought me was “visible”
The prototype came together fast for one reason.
I built the things you can see first —
movement, jumping, room transitions.
Anything that shows up on screen
the moment you hit build
makes progress feel fast.
What I didn’t understand yet
was how much of shipping a game is invisible.
Save and load.
Edge cases.
A tutorial.
A settings screen.
Checking behavior across different devices.
None of that looks like anything when you build it,
so it kept sliding down the list.
Actual dev footage. Left: February 1, idle state only. Right: February 15, jump state and a score counter working.
My actual desktop around day 15 — the game window, my own BGM work, and the code editor all open at once.
What was still missing before beta
Here is what actually ate the time after the prototype.
Whether progress survives closing and reopening the game.
Whether a dropped connection or a forced quit breaks anything.
Whether someone who has never seen the game
can figure out the controls with no explanation.
Whether it looks right across different screen sizes.
Whether ads and store purchases actually work.
Actual code from around day 15 — writing object events and score logic by hand.
At the prototype stage
the only question was “does this work at all.”
Getting ready for beta meant asking
“does this work for a stranger who has never touched it.”
The bar moved.
So did the amount of work left.
Fast progress and real readiness move at different speeds
A fast prototype does not mean a launch is close.
A prototype proves the idea works as a game.
A beta proves it doesn’t fall apart in someone else’s hands.
Those are different goals,
so the time each one takes behaves differently.
Now, hitting a working prototype
doesn’t make me expect the next stretch to go faster.
I split what’s left into visible work and invisible work
before I estimate anything.
If you’re starting out
Write down the invisible list on day one,
before you build anything.
Save and load.
Error handling.
Tutorial.
Settings.
Device testing.
Store and ad integration.
You won’t build them first,
and you shouldn’t.
But having them written down
changes what a working prototype means to you.
It stops reading as “almost done”
and starts reading as “the visible half is done.”
That one shift would have saved me
weeks of bad estimates.
How I’m applying this to the sequel
While building Call the Cat: Galaxy,
I’m setting up the save structure and basic error handling
starting at the prototype stage — not after it.
Building only the visible features first
and dealing with everything else in one batch later
is exactly what stretched the gap on the first game.
This time the prototype-to-beta stretch gets a checklist up front
instead of getting discovered as I go.
Knowing what’s left in advance means that when progress slows,
it reads as “this is normally the slow part”
instead of “why isn’t this working.”
Solo dev of Call the Cat, shipped after 178 days
on Google Play
and Steam.
Now building the sequel, Call the Cat: Galaxy, in public.