Should we build a website, WeChat mini program, or app first?

Start with a responsive website when discovery depends on search, external links, and cross-platform reach. Start with a WeChat mini program when the primary journey begins with QR codes, official accounts, groups, or in-store service. Evaluate an app when use is frequent and depends on robust offline work, background tasks, or deep device capabilities. Without evidence for all three, build one primary client first.

Primary client	Strongest use	Entry and release	Main risk
Responsive web/PWA	Search acquisition, content, public lookup, infrequent tools	Link opens immediately; updates without store review	Retention, push, background, offline, and permissions vary by browser
WeChat mini program	QR, official account, group, store, and lightweight transaction	Short WeChat journey without traditional install	Category, qualification, review, and ecosystem constraints
Native or cross-platform app	Frequent membership/staff/device work, strong offline, complex interaction	Rich local and system integration; store review and version maintenance	Installation loss, iOS/Android support, continuing cost

When comparing platform capabilities, constraints, and switching costs, also compare Can a website, mobile web, admin system, mini-program, and app share one product plan? and What should be validated before building a mini-app for an overseas market?; the linked guidance adds context that should be considered in the same decision.

“Apps always retain better,” “mini programs are always cheaper,” and “a PWA is the same as an app” are unreliable. Value and frequency drive retention. Complex transactions, streaming, hardware, and compatibility can make a mini program expensive. PWA behavior must be tested on target operating systems and browsers.

Wavesteam gathers traffic sources across ordinary and campaign periods, device and channel mix, task frequency, acceptable journey length, weak/offline prevalence, push and background needs, Bluetooth/NFC/camera/files, and the need for indexable deep links. We then build comparable prototypes for the highest-frequency, conversion-critical, and capability-constrained tasks and test them with real users and representative devices.

Measure arrival, first authorization, task completion, time, failure, crash/blank-screen, weak-network recovery, and release effort; for commerce, follow click or scan through payment. If discovery mainly comes from indexable pages, web usually wins. If the journey begins inside WeChat or a physical store, mini program usually wins. If the essential repeated task fails without offline, background, or specialist hardware access, app becomes credible. When channel shares are close, use measured acquisition cost, customer value, and capability results—not a universal percentage.

A shared backend does not make additional clients free. Identity, orders, content, and access can share APIs and design rules, but every client still needs navigation, consent, payments, notification, privacy, review material, device testing, and accessibility. Cross-platform frameworks reduce duplication without eliminating behavioral differences.

The usual sequence is primary client, reusable backend, measured use, then a second client when evidence supports it. Apple states that apps, updates, in-app purchases, and events undergo review and lists submission requirements in its review overview and guidelines. WeChat service categories and qualifications should be checked before build. No developer can guarantee approval.

Wavesteam's final recommendation is simple: the primary acquisition path selects the first candidate, critical task capability can veto it, and real conversion and task evidence decides whether another client earns its cost.