One lunchtime, I looked around the office and saw a few colleagues repeatedly playing a reflex test site. They were retrying for tens of minutes just to shave off 10ms. Watching them, I had two thoughts: "This game has a real hook to it," and "That can't be too hard to build." That's how the first mini-game got started.
The First Game Was As Easy As Expected
The reflex test itself had no difficult parts. When the screen changes color, click — measure the reaction time — show the result. The logic was simple enough that Gemini put together the basic framework quickly, and I focused on polishing the design. Having built up some experience from making multiple psychology tests helped too. Once you finish one, the next game idea naturally follows, so I went ahead and built the Aim Trainer as well.
After that came Memory Test, then 1 to 50. Each game had different logic, but the approach was similar — I described the game idea, Gemini produced the basic implementation, and I played it myself and iterated on feedback.
But As Games Multiplied...
Psychology tests had similar result structures, so they could be handled with a single shared page. Games were different. The reflex test averaged 3 rounds, the aim trainer accumulated points over 30 seconds. The number of rounds, whether there was a timer, how scores were calculated — all varied by game, so "just plug it into the same page" didn't work. In the end, I had to build a near-fresh page for each new game.
It Needs a Ranking to Be Fun
After building a few games, I played them myself several times and felt something was off — flat, somehow. Seeing just your own score felt like half the fun. Remembering how colleagues used to compare scores at lunch, I thought a global user ranking would drive the urge to replay. I decided to add a ranking system divided into daily, weekly, and monthly leaderboards.
Building a Ranking System Without a Backend
Once I committed to adding rankings, a practical problem appeared. A ranking system needs to store user data somewhere on a server — and up to this point, there was no backend at all. As I mentioned in the first post, spinning up a Java/Spring Boot server would have been overkill. I needed a new way to handle the backend. I asked Gemini, and for a simple use case like this, it recommended Firebase — storing data in Firestore and handling server logic with Functions. This was the moment I brought Firebase into the project for the first time.
Firebase was a service I had never used before. Gemini handled the code integration, which was fine as expected. The real blocker was the configuration inside the Firebase dashboard.
Friends Started Replaying Obsessively
After adding the ranking system, I showed it to friends first. The reaction was interesting. They kept retrying because they weren't happy with their scores. Especially on the reflex test, every time the number one spot changed hands, it pushed them to go again. It was exactly the same pattern as my colleagues spending half their lunch on someone else's reflex test. I thought: this is working as intended.
Looking Back: What I Regret
Looking at Q-Fit's game list now, you can see that button sizes, font sizes, and result layout positions vary slightly from game to game. It's because I didn't document game UI standards sufficiently early on. For psychology tests, I unified the result page structure early and successfully extracted a shared component — but I didn't do the same for games. Even after adding the ranking system, I didn't define upfront standards for how rankings would appear on result screens or how button styles would be unified.
Eventually, I built shared game components and hooks and tidied up the guides, which brought things somewhat into alignment — but that process took a fair amount of time. I still think it would have been much smoother if there had been standards from the start.
What I Learned From Building Games
Building mini-games gave me some insight into what drives repeat play. Just being fun isn't enough. You need the curiosity of "Where do I rank?" and the feeling of "One more try and I might move up." The ranking system satisfied both. Of course, adding a ranking doesn't automatically make every game more fun. The prerequisite is that the core gameplay needs to be worth repeating in the first place.
Also, games give 'try it and you'll know' feedback much faster than psychology tests. Play for just five minutes after building one, and you get a rough sense of whether it's fun or not. That quick feedback cycle is what let me build several games in relatively short order. In the next post, I'd like to talk more about the process of building common structures as the number of games kept growing.
