My experience building a Cricket card game.

This is the story of how I built Cricket Top Trumps — a game I loved as a kid — shipped it to real users, gathered feedback, and ultimately decided to walk away.

TL;DR — I built and published Cricket Top Trumps, ran two build-feedback cycles, and after honest reflection, accepted it as a valuable learning project rather than a product worth pursuing further.

Ideation & MVP

(Time consumed: 3 days)

It started with a memory. I was sitting around one day when a childhood game came to mind — cricket cards. The rules are simple: you pick a stat from the top card on your deck, and if it beats your opponent’s card on that same stat, you win their card. Keep collecting until you have them all.

I wanted to bring it online. Before writing a single line of code, I checked if someone had already built it. There was an Android app, but I felt I could do better. I spent some time nailing down the game rules, then used Google AI Studio to draft a Software Design Document. A few iterations later, I had a solid spec.

For building the project, I turned to OpenAI Codex. I laid out the requirements clearly enough that Codex produced a working MVP on the very first run. A few test rounds confirmed everything was working as expected.

Designing the UI

(Time consumed: 1 day)

The MVP worked, but it looked exactly like what it was — an AI’s first draft. I knew I had to own the UI myself. Designing the player cards was the hardest part; I browsed through various reference designs before landing on something I was happy with. Once I had the design locked in, implementing it was straightforward.

Deploying the Application & User Feedback

(Time consumed: 3 days)

With a working, presentable version in hand, I deployed it and shared it with a small circle of friends for feedback. The response was clear:

• The UI felt too basic.
• Stats were small to read on mobile screens.

Around this time, my ambitions started to grow. I began thinking about marketing the game to cricket fans and exploring monetization through ads. I went as far as purchasing a domain — cricketnerds.com — with the vision of building a broader cricket-themed platform to drive traffic.

Redesigning the UI

(Time consumed: 10 days)

The feedback pushed me to take the UI seriously. I studied fantasy sports games from the US market for inspiration and put together a new design direction. I then used an LLM to push the concept further — asking it to make the design futuristic and polished. The result was something I was genuinely proud of.

Marketing, Feature Updates & User Feedback

(Time consumed: 7 days)

By early March, the redesign was live. This time, I went public — posting on Reddit, Instagram, and X. Reddit drove the most traffic and the most useful feedback.

The overall response was positive, but users wanted more depth to keep them coming back. Here is some feedback I received:

• Add more players.
• Add in-game sounds.
• Add animations.
• Add difficulty levels (easy, medium, hard) when playing against AI.

Self-Reflection

With a feature list in hand and a few hundred players, I was ready to commit another week to the project. But before diving in, I paused to ask myself some harder questions:

• Do people genuinely enjoy this game?
• Will they come back and play it again?
• Am I building in a bubble, ignoring whether people will play this game?
• Is this the best use of my time?

I reached out to a few trusted friends for brutally honest opinions. Their answers were sobering. The consensus: it feels like a personal project. Games need to be addictive. Even if you monetize it, how much can you realistically make?

Their feedback landed. When I reflected honestly, I realized I had no good answer to the most important question: Will people come back? Without retention, continued investment didn’t make sense. I had started this out of curiosity — to build something I loved as a kid — and that goal was already achieved.

So I put the project aside, carrying the lessons forward from a 25-day journey well spent.

My Learnings

• Validate before you build. Understand whether people would actually use and pay for a product before investing deeply in it.
• Design and architecture matter from the start — retrofitting them is expensive.
• Don’t just vibe-code — understand what you’re building and why.