An Uncomfortable Starting Point
In early 2024, I was working full-stack at a company building internal management tools. Stable job, solid technical skills, but I felt a growing sense of... emptiness.
The things I built — no one cared about them.
That's not quite right. People used them. But they used them and moved on. No feedback, no delight, no "wow" moment. I wrote code every day without knowing if it ever made anyone happy.
So I started asking: Is there a product where users say "that was fun"?
Why Puzzle Games
I'd noticed a strange gap in the market: mobile puzzle games were drowning in ads and paywalls, while web-based puzzle games were stuck in the 2010s.
I remember waiting for the subway once, opening my phone to play a quick Sudoku, and getting two ad pop-ups in the first three moves. I thought: If there was a clean, ad-light, multiplayer-capable Sudoku site, I'd use it every day.
That was the first "why."
The second was more technical — I wanted to verify something: Can modern web technology deliver a near-native real-time gaming experience?
WebSocket, Angular Signals, Go's concurrency model... I wasn't using these at work, but I was curious about them. Puzzle games are a perfect validation ground: clear logic, predictable state, genuine real-time requirements.
My Market Assumptions (Some Were Wrong)
✅ Puzzle games are evergreen content
Unlike MOBAs or battle royale games, puzzle games don't have version drift. Sudoku is Sudoku. The rules don't change, the fun doesn't expire.
This meant: what I built wouldn't become obsolete. I could accumulate games slowly, without racing against a meta.
✅ The web puzzle game market is severely underserved
Search "online sudoku" — the top results are often sites that look like they were last updated in 2012. jQuery, Flash remnants, no responsive design.
But the search volume is real and stable. Demand exists. Supply is old. That's opportunity.
✅ Bilingual support is a real differentiator (but harder than expected)
My reasoning: if I properly support both Chinese and English, I double my addressable audience while most competitors only target one language.
This held up. But implementing it was harder than I expected — routing, SEO, translation keys, content strategy all needed independent design. I'll have a full article on this.
✅ Real-time multiplayer is the core differentiator
"Play with a friend" is a need that puzzle games have almost entirely ignored. Most puzzle games are solo experiences.
I wanted to build: two players in the same room, racing to complete Sudoku in real-time, first to finish wins. Almost no web product was doing this.
This was also the hardest part to build. WebSocket state sync, disconnect handling, a shared backend across 14 game types... problems I spent months actually solving.
🔶 Content-driven traffic would come naturally (partially right)
I thought good SEO plus good content would generate traffic automatically.
Reality: SEO is a long-term investment. The first three months, I could count daily visitors on my hands. But after month 3, the curve started tilting upward.
The Moments That Made Me Actually Start
After thinking about this for months, two specific moments turned "maybe" into "let's write code."
Moment 1: I showed a friend a 30-minute Sudoku prototype (no styling, pure logic). He played for 10 minutes, then said: "This would be great if you could play against someone."
That was it. Not market research, not an MVP framework — just one friend's one comment.
Moment 2: I read an article about Angular's Signals system. The author wrote: "This is the most significant update in Angular's history — it makes state management genuinely intuitive."
I thought: that's exactly what game state needs. Game state is dense and rapidly changing — player positions, scores, countdowns, opponent state. Managing that with NgRx or BehaviorSubject would produce mountains of boilerplate. Signals are designed for exactly this pattern.
Tech stack chosen. Motivation clear. I opened VS Code, created a new folder called x-game, and started writing.
Three Constraints I Set for Myself
Before starting, I set three rules. These rules saved the project:
Rule 1: Get one game right before expanding.
Many people building platforms try to launch 10 games at once. They end up with 10 half-finished games and nothing worth playing. I started with Sudoku. Until Sudoku was good, no new games.
Rule 2: No fake traffic, no paid ads. Real users only.
I wanted to verify whether real people would voluntarily use this. Paid traffic can't answer that question.
Rule 3: Ship something demonstrable every week.
Not "released." Just "something I can show someone." This forced real progress every week and prevented infinite polishing loops.
A Year Later: Was It Worth It?
Yes.
Not because of money (monetization is a separate topic). But because for the first time in years, I built something and real people used it, played it, and occasionally said "this is fun."
That feeling — I couldn't get it building internal tools.
Next: *[02] Tech Stack Decisions** — why Angular 21 Signals + Go Fiber, and what I'd choose differently today.*
