Building and Launching a WeChat Mini Game from Scratch with AI: Writing Code Was the Easy Part

Last month, the first WeChat Mini Game I built, English Word Bento Box (《英语单词收纳盒》), was officially launched.

The core gameplay can be explained in a single sentence: sort English vocabulary cards into the correct category boxes. When you see APPLE, drop it into FOOD; when you see RAIN, drop it into WEATHER. The initial release includes 150 main levels, over 800 words, plus foundational features like daily reviews and progress tracking.

The game itself is compact, but the process helped me validate a question I had always been curious about: Can someone with zero game development experience, with deep AI involvement, independently take a game from initial concept all the way to a live production release?

The answer is yes. But once it was truly live, I discovered something much more important—and humbling:

AI dramatically lowers the barrier to “building something,” but it does not make “building a great product” any easier. In fact, in many ways, the latter becomes even harder.

In this article, I want to share the pitfalls I encountered and the key insights I gained throughout the journey.

Why “Word + Categorization”

The starting point was straightforward: I wanted a lightweight gameplay loop that broke away from the traditional rote learning pattern of “view English → read Chinese translation → memorize → answer test questions.” Especially for young children, that pattern reverts to boring study software after just two rounds.

Then the idea of “categorization” came up. Seeing the word Apple requires not just knowing it means “苹果”, but actively determining that it belongs to the Food category. Seeing Pencil requires recognizing its connection to school and learning scenarios. Through this mechanism, vocabulary is no longer isolated translation pairs, but is anchored directly to concrete semantic contexts.

The core loop of “word cards + category boxes” was decided, and the project was naturally named English Word Bento Box.

Alibaba Cloud - Top choice for developers, exclusive 15% off for Lighthouse servers

Get 15% Discount →Ad

For the first version, I deliberately kept my ambition modest: no character progression, no equipment systems, no narrative storylines. I only wanted to validate one core thesis: Does learning and reviewing vocabulary through semantic categorization actually work as a fun mechanic? 150 levels connecting the full loop of “first encounter → in-game judgment → repeated exposure → spaced review” were more than enough for a minimum viable product.

Looking back, making the core hypothesis playable before anything else was the right call. Many critical problems only reveal themselves when you actually play the game; sitting at a desk theorizing will never uncover them.

This Time, AI Did Much More Than “Just Write Code”

Simply saying “this game was built with AI” is nothing novel today. What I wanted to explore was something broader: instead of treating AI purely as a code generator, having it participate across the entire product lifecycle from ideation to launch.

In practice, AI took on at least five distinct roles in this project.

Product Manager. The earliest challenges were not coding problems at all: How much scope is enough for version 1.0? At which level should daily reviews unlock? How should new words be balanced against review words? How many categories should appear per level so it does not feel like an exam? All of these required clarifying product logic before writing a single line of code.

Game Designer. Manually configuring 150 levels was not only labor-intensive, but difficulty curves could easily spin out of control. After structuring the vocabulary, categories, introduction order, and review ratios, I had AI validate the level data against strict rules: Which category does this word belong to? Which categories can appear simultaneously on one screen? Are there sudden spikes in difficulty between adjacent levels? Are there any inappropriate terms for young learners? What used to be manual spreadsheets turned into “rules + structured data + AI auditing.”

UI/UX Design Assistant. How to arrange main campaign and review entry points on the home screen, what data to display after clearing a stage, how to make a child feel “I truly accomplished something” rather than just showing a dry “Stage Cleared” prompt—all these interfaces went through extensive iterations. AI drafted layouts and prototypes, which were then immediately tested and refined inside the game engine.

Software Engineer. The game was developed in Cocos Creator. From gameplay mechanics, save systems, and UI states to WeChat Mini Game platform adaptations and automated build scripts, a large portion of implementation was written by AI. My role shifted to: define requirements → inspect output → playtest → identify issues → refine constraints → iterate. The biggest transformation was not needing months to master engine APIs before building a demo; I could start directly from “what I want to build” and work backward into technical understanding.

QA & Testing. This is often the most overlooked role, but in my experience, it provided the highest leverage. In the latter stages, I spent increasingly more time on testing: unit tests, data integrity checks, level configuration audits, automated browser tests, and pre-release smoke checks. Many of these audits were packaged into one-click scripts. In other words, AI was tasked not only with “writing features,” but also with “proving that new features did not break anything else.” The value of the latter is on an entirely different scale.

Writing Code Was Never the Hardest Part

Reaching this stage brought a subtle realization.

Before knowing how to program, one often assumes: “If only I knew how to write code, I could build this easily.” Now that AI handles most of the technical execution, you suddenly encounter the much larger mountain behind it: Is this actually fun to play?

The most prominent example was level difficulty. On paper, everything in the first version was logical: structured stages, step limits, expanding vocabulary, and increasingly diverse categories. But after personally playing through fifteen or twenty levels consecutively, I realized—it was far too easy. Many levels ended with huge surpluses of remaining steps.

Railway - Modern deployment platform, zero-config, go live in minutes

Start Now →Ad

From a software engineering perspective, the system was flawless: zero bugs, correct win/loss detection, and valid state transitions. But from a game design perspective, it created no tension or meaningful decision-making.

That moment brought visceral clarity: software correctness and player experience are evaluated on two completely different systems. AI can verify whether code logic is correct and batch-generate 150 levels according to specifications, but whether “level 20 becomes boring” can only be discovered through real human playtesting.

Target audience assumptions followed a similar path. I initially designated the game for “ages 6+”. A friend playtesting with their child pointed out something fundamental: for young children, a text-heavy UI requires reading literacy before gameplay even begins. If the font size is too small, the barrier multiplies. It sounds painfully obvious, yet when you are laser-focused on implementing features, blind spots like this are remarkably easy to miss. That led to deeper trade-offs: Should every word have an illustration? Should fonts be enlarged? If illustrations are added, will children only look at the picture and ignore the English text? These are no longer programming questions; they have no formulaic answers and demand continuous judgment.

Educational Games: Should They Feel More Like “Learning” or “Gaming”?

This has become the question I find most worth pondering.

If an educational game simply wraps animated graphics around textbook exercises, it remains a textbook exercise at its core. A player places a card into a box, it vanishes with a click, and the next card appears—functionally complete, but the sensation of play is close to zero.

Mature games use continuous, tactile micro-feedback to reassure players that they just did something satisfying: the dynamic snap of a card sliding into a box, dispersing particle effects, stars flying into progress meters, ascending audio pitch on winning streaks, combos, and rewarding fanfare upon level completion. Individually, each is a small detail; combined, they determine whether a player feels they are “solving an exercise” or “playing a game.”

I have come to strongly embrace a core philosophy: Rather than trying to make learning look entertaining, focus first on making the game inherently fun, allowing learning to happen naturally through positive feedback loops. These two phrases may sound similar, but they represent entirely divergent design paths.

Crossing the Chasm from “Runs Locally” to “Live in Production”

Another phase that is easily underestimated is the launch process itself. Getting a game running on a local development machine represents at most half the journey. Publishing to WeChat Mini Games entails an extensive pipeline: production Cocos builds, platform adaptation, package size audits, physical device testing, multi-screen aspect ratio scaling, icon and logo design, cover artwork, sharing graphics, compliance review assets, submission, handling rejections, and final deployment.

Experiencing this end-to-end reinforced a key lesson: The distance between building a working demo and delivering a product ready for real users is far greater than most developers anticipate. When developing alone, it is easy to fixate solely on feature code, but design, content, QA, platform compliance, analytics, and operational workflows are all integral parts of the product.

The moment the game cleared review and could be opened by anyone on WeChat, the experience diverged completely from local testing. Anyone could open the game, enjoy it, drop out after sixty seconds, or leave blunt feedback that “it isn’t fun.” In a private demo, you can always rationalize imperfections; once live in production, all questions converge into a single reality: Are real users willing to keep playing? That question cannot be answered with explanations.

Launching Is Not the Finish Line, but the Start of New Questions

To be candid, launching did not bring the relief of “finally being done.” Instead, it introduced a fresh set of questions: Do users actually start level 1 after entering? At which level does drop-off occur? Which words are most frequently miscategorized? Is anyone tapping daily review? Would adding illustrations improve retention for younger players?

Vultr - High-performance NVMe VPS with 32 global locations, one-click Docker deploy

View Pricing →Ad

For the next phase, I plan to focus not on blindly adding features, but on building data and feedback telemetry so real metrics guide subsequent iterations. Difficulty curves, tactile feedback, image experiments, and review mechanics will all be driven by observed behavior.

The initial launch taught me an enduring principle: Great products are not delivered by rigidly executing a static roadmap; they grow organically through real user feedback.

Closing Thoughts

Reflecting on this release, my primary takeaway is not that “AI writes code remarkably fast”—that aspect is becoming table stakes.

What truly matters is that for the first time, AI empowers a solo developer to orchestrate capabilities that previously required an entire multi-disciplinary team—product management, game design, UI/UX, full-stack engineering, QA automation, and data analysis—at minimal marginal cost. This does not mean AI replaces specialized professionals; on the contrary, building a real product illuminates the immense value of domain expertise. But historically, solo builders often never reached the stage of grappling with these higher-level product questions because the sheer friction of implementation exhausted all their energy. With implementation costs reduced, we can finally dedicate our focus to “what should be built” rather than “how to write this function.”

As for “what is worth building,” “what makes something truly fun,” and “what users genuinely need”—no prompt can hand you those answers out of the box. And that, perhaps, is the most rewarding aspect of product creation.

The initial version of English Word Bento Box is now live on WeChat Mini Games. If you have elementary school children at home, you can search for “英语单词收纳盒” on WeChat to try it out.

More than casual compliments, the feedback I value most is: Which levels felt dull? What was confusing? Did your child want to play another round? Which parts felt too much like studying rather than playing? This direct feedback will shape the next evolution of the game.

I will continue documenting how level tuning, telemetry analysis, and AI-assisted testing evolve in subsequent iterations. If you are interested in this journey, stay tuned.