What I Learned Building a WeChat Mini Program as an Indie Developer

1. Identity Verification: From Domain to Residence‑Permit Odyssey

The first step for an individual developer is to complete the mini‑program filing. Although the author already owned a domain registered in Sichuan, the mini‑program required additional filing information. Because the registration address differed from the developer's residence, a residence‑permit had to be obtained online via the Sichuan micro‑household service and then uploaded, finally passing the identity verification for a modest fee of about 30 CNY.

Software engineer certification requires a published paper or exposure in a major media outlet.

2. Public Platform vs. Open Platform: A Split Account Dilemma

Initially the author planned a web front‑end using WeChat QR‑code login, which necessitates the WeChat Open Platform and linking the mini‑program to it. The two platforms—WeChat Public Platform and WeChat Open Platform—are separate systems that require distinct email accounts. The workaround is to create email aliases to avoid managing multiple accounts.

WeChat Open Platform and WeChat Public Platform are different ecosystems; they must be registered with separate email addresses.

After registering on the Open Platform and linking the mini‑program, the author discovered that web‑login capabilities are not available to individual developers. Attempts to apply for a web app, bind it, request QR‑code login permission, and complete developer certification all failed because personal developers lack the necessary permissions.

Workaround: build a custom account system, generate QR codes, and use the mini‑program’s camera to scan them.

Additional restrictions for personal developers include the inability to use WeChat Pay and the prohibition of operating multiple mini‑programs under the same account. The author originally designed a backend using unionId for cross‑program user identification, but the restriction forced a fallback to the simpler openid + module name approach.

The mini‑program category selection is also limited; the author finally chose the “Tool” category after the name containing “magician” was rejected for potentially implying a magic‑related app.

3. Front‑End Stack Choice: Taro vs. Uni‑app

When developing a mini‑program, the common front‑end frameworks are Uni‑app and Taro. The author, familiar with Taro, initially selected it, expecting a faster ramp‑up.

In hindsight, Uni‑app may be a better choice because its ecosystem is richer and its community provides more resources. Taro is based on React, while Uni‑app uses Vue; the author only knows Vue, making Uni‑app a more natural fit.

The author used Taro 4.19 and experimented with Claude Sonnet 4.5 for code generation, but the limited documentation led to many bugs, so the final implementation relied on the standard scaffolding. The experience suggests that Uni‑app could save time and effort for developers in a similar situation.

4. Mini‑Program Review: Unexpectedly Smooth

The project itself was small, and the review process encountered few issues. One notable requirement is that users must first view the mini‑program’s feature introduction before being prompted to log in, which is reasonable to avoid immediate permission requests.

In the end, the mini‑program went from nothing to a live product despite numerous pitfalls, and the author reflects on the challenges of solo development and the value of perseverance.