Website, mini program, mobile app or desktop app?

Direct answer

Begin with the task and distribution, not a favorite technology. A website often supports a low-friction test for a temporary search-driven problem. A mini program may fit use and sharing within WeChat. Evaluate a mobile app when device capabilities and repeated use matter. Consider desktop when global shortcuts, windows or file operations are central. A market’s supposed willingness to pay, acquisition cost or income multiple is not a universal fact.\n\nPractical suggestion: give the present choice an exit condition. If users will not install, return to a lower-friction entry point. If a critical system capability cannot work reliably, change delivery. Do not let sunk code decide the product.

When to use

• You have an idea but have not chosen a technical route.
• You already have a website and are considering several clients at once.

Step by step

Describe the task context

Which device, entry point, frequency and session length are involved? Must it use camera, files, notifications or background work? Replace a wish to build an app with a concrete user need.

Check how users arrive

Search, community links, stores, WeChat sharing and desktop workflows differ. Choose a form users will open. An installer does not automatically create trust, retention or new users.

Compare delivery and maintenance

Websites need browser compatibility; mini programs need platform integration and review; mobile apps need devices, signing, stores and native modules; desktop needs permissions, installation and updates. Cross-platform reuse reduces some code without removing platform-specific acceptance.

Verify the central outcome first

When form is uncertain, start with a low-cost web or interaction prototype and real feedback. If value fundamentally requires a native capability, test that capability directly rather than treating a web mockup as equivalent experience.

Define evidence for another client

Record explicit requests, repeat-use patterns and platform capability gaps. Expand only when evidence justifies added maintenance. Define interfaces for accounts, data and access that can be shared.

Include extensions and PWAs as candidates

Describe the actual entry task: use after search, open after a WeChat share, capture or work offline on a phone, invoke a desktop shortcut, or assist inside the current browser page. The last may favor an extension that removes copying and pasting. Chrome activeTab can grant temporary current-tab access after a user action; evaluate limited permissions when they fit rather than requesting every site by default. PWA capabilities vary by system and browser. An added icon does not prove offline support, and PWAs are not categorically unable to use hardware.

Build a capability and distribution probe table

Record entry point, critical device capability, input preservation and recovery, identity and data ownership, payment path, release responsibility and ongoing cost. Probe the unknown that decides the route on a real target: an alternative after camera denial or a useful warning for a shortcut conflict. Record only observed device and version coverage. Then estimate development, review, content, model and maintenance cost. Installation counts, platform scale and someone else’s income are not payment evidence for your product.

Worked example

Hypothetical exercise: meeting-note summaries

If users upload text through a link weekly and export a summary, a website can test the value first. Repeated requests for global capture shortcuts, local-file integration and background presence may later justify desktop. A competitor’s desktop client alone does not justify installation and update maintenance.

Action checklist

• The platform choice maps to a concrete task.
• Acquisition entry point and opening friction were considered.
• Additional review, permission and maintenance requirements are known.
• A minimal test exercised the central capability.
• Comparisons include real entry paths, critical capability probes and recurring cost.

Reusable templates

Product-form decision

User and core task:
Primary device:
Where the first users arrive:
Frequency and willingness to install:
Required system capabilities:
Candidate forms and limitations:
Reusable accounts, data and payment:
Review and maintenance cost:
Minimal verification:
Reasons to choose or defer each form:

Six-form comparison and capability probe

Task, frequency and setting:
Candidates: website or PWA | browser extension | WeChat mini program | mini game | mobile app | desktop app
For each: entry point | steps removed | system capability | permissions and denial path | data ownership | payment | review or updates | ongoing cost
Unknown that determines the route:
Smallest probe, target device and version, observed result:
What this probe cannot establish:
Current choice and reason:
Exit or switching condition:
Evidence that would justify another client:

Pitfalls

• Claims of dramatically higher foreign-market income or near-zero acquisition cost are not general evidence.
• PWAs, cross-platform and native clients each have constraints; no route is right for every product.
• Code reuse does not remove the need to test each platform.

Related guides

• How do I build and release a WeChat mini program?
• How do I turn a web product into a mobile app?
• How do I build and distribute a desktop product?

Official references

• Chrome Extensions: activeTab. Documentation review recorded: 2026-10-18; confirm the applicable version before use.