I am a software engineer by day. By night, I am also a software engineer — but a chaotic one who makes tiny games nobody asked for.
This is the story of how I went from "I'll just try making a simple puzzle game" to three live projects and a 12-year-old golden retriever who has definitely seen me debug at 2am.
The First Game
It starts innocent enough. You think: how hard can it be? You've been writing code for 20 years. You know React. You know JavaScript. A little game? Easy.
Reader, it was not easy.
But it was fun. And that's the thing about making tiny games — they scratch a completely different itch than building production software. There are no stakeholders. No tickets. No "can we add a dark mode by Friday." Just you, your weird idea, and infinite freedom to make it exactly as stupid as you want.
On Tiny vs. Big
There's a culture of ambition in indie game dev. Everyone wants to make the next Stardew Valley. Someday, maybe me too. But right now, I love the constraint of small.
Guess My Number. 2048 Trouble. Duzzle. Three tiny games — all "can you finish it in a weekend" sized. Two of them live on their own domains, one of them lives here. Different homes, same idea. And there's something deeply satisfying about that. You have an idea on Friday, you ship on Sunday, and by Monday you're already thinking about the next one.
Small scope = high completion rate = actual joy.
Why JavaScript?
Because it's what I know best. And because the barrier to putting something on the internet is basically zero. No build pipeline hell. No platform fees. No gatekeepers. You make a thing, you deploy it, strangers in Turkey play your word puzzle. That's magic.
The Secret Ingredient
I've figured out the formula: make something that you would want to play. I like number puzzles and word games and things with a little chaos in them. So that's what I make.
Also: party mode. Every game needs a party mode.
Poco's Opinion
He doesn't have one. He's been asleep the entire time I've been writing this.