Many teams doing a Mini Program for the first time tend to treat it as a "shrunk-down App," and end up hitting pitfall after pitfall around category qualifications, review rules, and performance limits. In fact, Mini Program development from 0 to 1 follows a relatively fixed process — as long as you advance stage by stage, most problems can be avoided in advance. Below is a walkthrough following the actual project rhythm, with common pitfalls flagged along the way.
1. Requirements and Feasibility Confirmation
Before writing any code, answer three questions:
- What category are you building in: e-commerce, tools, content, booking, internal enterprise applications — different categories come with very different qualification requirements and review standards.
- Who will use it: C-end users care about experience and sharing paths; B-end users care about permissions and data export.
- What is the core loop: getting one or two main flows working is more valuable than piling up ten half-finished features.
At this stage, it is recommended to produce a "feature list + priorities" and clearly define the MVP scope. Many projects are delayed not because development is slow, but because requirements keep getting added mid-development.
Pitfalls to Avoid
- For categories involving healthcare, finance, education, livestreaming, recruitment, etc., check the platform's qualification requirements in advance — don't wait until development is done to discover the category can't be opened.
- For capabilities such as payments, obtaining phone numbers, and geolocation, first confirm whether the entity type (individual / enterprise / sole proprietorship) supports them.
2. Prototyping and UI Design
Use Axure, Figma, or Modao to draw the main flow pages. The key is not looking good, but thinking clearly about navigation relationships and exception states:
- How to display empty states, loading states, network failures, and no-permission states respectively;
- Form validation rules and error prompts;
- Titles and cover images for share cards and Moments sharing.
It is recommended to produce design mockups directly at common Mini Program dimensions (such as a 750rpx baseline) to reduce conversion costs during development.
3. Technology Selection
There are three mainstream paths:
1. Native development: Official WeChat/Alipay frameworks, with the best performance and compatibility, suitable for projects with high experience requirements.
2. Cross-platform frameworks: uni-app, Taro — one codebase published across multiple platforms, suitable for teams that need WeChat, Alipay, and Douyin Mini Programs at the same time.
3. Low-code platforms: Suitable for marketing campaign pages and simple forms; complex logic will be limited.
For the backend, you can choose self-built services (Node, Java, Python all work), or use cloud development first for rapid validation. It is recommended to prioritize solutions with high development efficiency during the MVP stage, and consider refactoring only after the business is running.
4. Development and Integration
During development, it is recommended to proceed module by module, merging only after each module passes self-testing:
- First set up the three essentials: request encapsulation, login state management, and error reporting;
- Reuse components across pages following the common "list—detail—form" pattern;
- Use Mock data for parallel progress during API integration — don't wait for the backend to be fully complete.
Common Technical Pitfalls
- Main package size exceeds the limit: WeChat's main package is limited to 2MB; images, fonts, and large dependencies should go into subpackages or a CDN.
- Frequent setData calls: Passing large amounts of data at once causes lag; merge updates and only pass changed fields.
- Login state expiration: After exchanging code for session, handle expiration and re-login — don't assume one login is valid forever.
- Payment callback: Payment results must be based on server-side asynchronous notifications; frontend callbacks should only be used for display.
5. Testing and Experience Optimization
Before launch, at minimum cover:
- Real-device testing on mainstream models (iOS / low-end Android devices);
- State recovery under weak network, disconnected network, and returning from background;
- Secondary guidance after the first authorization rejection;
- Performance panel checks for first-screen time and memory usage.
6. Submission for Review and Launch
Before submission, check: category and qualifications, privacy agreement, user information collection statement, and content compliance. Common reasons for review rejection include: incomplete features, induced sharing, category mismatch, and missing privacy policy.
Rejection is not scary — revise item by item according to the feedback and attach explanations; usually a second submission will pass. After launch, it is recommended to integrate data analytics and error monitoring, and use real data to drive the next iteration.
7. Practical Advice for Teams
- Treat review rules as part of the requirements document and check against them during the design stage;
- Keep a fixed release rhythm and move in small, fast steps — don't save up for one big release;
- Keep a "pitfall log" and reuse it directly in the next project;
- Don't skip security testing and API authentication — privilege escalation vulnerabilities are just as common in Mini Programs.
Mini Program development itself is not hard; what is hard is taking care of the process, rules, and details. Following the process above, launching from 0 to 1 can usually be kept within a reasonable timeline.