Building a Mini Program with AI: The Hard Part Isn't the Code

Starting from a Real Pain Point

Most tech projects begin with grand ambitions, but the WeChat Mini Program "Sit Less, Move More" shared by this Bilibili creator had a refreshingly relatable origin — after sitting for long stretches, his left shoulder would start to ache. He knew prolonged sitting was bad for his health and had searched for similar tools on WeChat, but they either didn't allow custom reminder intervals or required filling out a pile of information.

What he actually wanted was dead simple: pick a time interval, hit start, get a reminder to stand up, tap "I'm up" to reset the timer. Since nothing quite fit the bill, he decided to build it himself.

This starting point may seem ordinary, but it contains the most important methodology of the entire project — first get clear on the actual problem you're trying to solve. Now that AI has dramatically lowered the barrier to development, the real value of this story lies in a counterintuitive truth it reveals: writing the code itself turned out to be the least difficult part.

You Don't Have to Learn Everything Before You Start

Having never built a WeChat Mini Program before, his first instinct was to hunt for tutorials on Bilibili and similar platforms. But comprehensive tutorials typically run ten-plus hours, and unfamiliar concepts like certification, ICP filing, and cloud functions kept surfacing. The more he watched, the more complicated it seemed — and the idea sat on the shelf for a while.

The turning point came when he stumbled across some examples of people building mini programs with AI. He realized: he didn't need to master the entire knowledge base first — he could start by clearly describing what he needed and build a minimum viable product (MVP).

This represents an important shift in the development paradigm of the AI era. In the past, technical barriers meant you had to systematically acquire knowledge before you could act. Now, registering a mini program, verifying a subscription message, getting a single notification to actually deliver — these small, hands-on starting points are often far more effective than watching hours of tutorials. Action itself becomes the best learning path.

Cutting Features Is Harder Than Adding Them

During the product design phase, his initial vision was quite ambitious: not only tracking sitting time, but distinguishing between "standing" and "getting up to move," even supporting sit-stand desk switching. But after discussing it with AI, he realized that while all these features had valid use cases, they would make the most common interaction unnecessarily complex.

For most users, getting a reminder and stepping away from the chair for a moment is enough. So the first version kept just one core action — "I'm up" — which simultaneously logged a movement and reset the timer. Everything else was pushed to later.

"Building a product isn't about adding every feature you can think of. Sometimes deciding what to cut is more important than deciding what to add."

This gets at the essence of product design. AI can help you rapidly implement any feature — but precisely because implementation has become so easy, the judgment to hold back becomes rarer and more valuable.

AI Can Accelerate Execution, But Can't Think for You

On the technical side, he initially considered a heavy-weight architecture — Spring Boot, MySQL, Redis, and a dedicated server — but eventually switched to native WeChat Mini Program plus Tencent Cloud CloudBase. This way, he didn't need to set up a server or domain name upfront, and could validate the idea much faster.

But once the mini program was actually running, what confused him most wasn't any single line of code — it was how the frontend mini program, cloud functions, and triggers were supposed to work together. He had published the frontend and deployed the cloud functions, yet the WeChat backend notifications never arrived. After digging in, he found the culprit: triggers need to be uploaded separately. Uploading the mini program code is not the same as deploying cloud functions, and deploying cloud functions is not the same as uploading triggers. Without that final step, the cloud function would never scan on a schedule — and naturally, no reminders would ever go out.

Once he mapped it out, the entire notification flow became clear: when the mini program is in the foreground, the page handles the countdown and triggers the alert directly; when it moves to the background, the frontend can no longer run reliably, so a scheduled cloud function periodically scans and calls the WeChat API to send a service notification. Both paths share the same cloud-stored timer state, but each handles a different scenario.

The lesson here is critical: even when developing with AI, you can't just focus on whether the code was generated. AI can handle the specific implementation, but the developer still needs to know what components make up the system, where the data comes from, and how each step connects. AI accelerates execution — it can't replace your understanding of the system, or your responsibility for the decisions.

Optimizing User Experience Within Platform Rules

WeChat subscription messages come with an unavoidable constraint: a single authorization typically allows only a limited number of messages to be sent. The mini program can't send unlimited reminders just because a user agreed once.

Originally, he wanted to show an authorization confirmation every time the user tapped "Start" or "I'm up." The logic was clean, but what should be a single tap became a two-step action. He eventually changed the flow: the authorization prompt appears only on the first tap of "Start," and users can check "Allow by default" in the WeChat prompt. After that, if default permission is granted, WeChat handles it automatically — no more repeated confirmations.

"I can't work around WeChat's rules, but I can try to explain them clearly and reduce the burden on users."

At this point, the problem is no longer about code — it's about helping users understand what's happening without getting lost in technical jargon. This is the part of product design that demands the most empathy.

The Art of Trade-offs Under Resource Constraints

Launch testing exposed a multi-device sync issue: when a phone, computer, and tablet were all open at the same time, tapping "I'm up" on one device wouldn't immediately sync to the others. To fix this, he had the frontend poll the cloud for state updates every 5 seconds. It worked, but the cost was obvious — the frontend was constantly reading data that almost never changed.

The background trigger was an even bigger concern. The original version ran every 30 seconds — even when nobody was actively timing anything — generating a fixed 2,880 calls per day, or 86,400 over 30 days. Switching to once per minute brought that down to 1,440 per day and 43,200 over 30 days. Against a monthly quota of 200,000 calls, the scheduled trigger's fixed overhead dropped from 43.2% to 21.6% — and that's before counting any calls from user interactions.

After rethinking the trade-offs, he decided to prioritize the core experience: after the mini program is opened or interacted with, it polls at 5-second intervals for only 15 seconds — a maximum of three additional requests — then stops. Foreground alerts continue running locally, and the second device re-syncs with the cloud when it comes back to the foreground.

The trade-off is that multiple devices no longer stay in perfect sync, and background reminders might be delayed by a few dozen seconds. But multi-device use is a low-frequency scenario, and continuously burning resources to support it — potentially undermining the core reminder feature — simply isn't worth it.

"Doing things right doesn't mean perfecting every aspect of the user experience. When resources are limited, you need to ensure the stability of the core functionality first."

Four Lessons That Go Beyond Code

Looking back, this mini program started from a humble place — but what it left behind isn't just a reminder tool. It's four genuinely instructive takeaways:

1. Ideas can grow naturally from real-life needs — something has to be useful to you first before it can be useful to anyone else;
2. You don't need to learn everything before you start — getting a single notification to actually deliver beats watching hours of tutorials;
3. Even with AI, you still need to understand the overall architecture — AI helps you execute faster, but it can't take on the burden of judgment for you;
4. Distinguish core features from non-core ones — when resources are limited, the act of trade-off is itself part of the product.

Now that AI has made "writing code that runs" increasingly easy, the truly scarce skill is exactly what this creator kept coming back to — knowing what actually matters right now. That may be the core competency developers should hold onto and sharpen most in the age of AI-assisted development.