Bottom line: a European connected-gym-equipment brand wanted Chinese users to scan a QR code on a machine, log in through WeChat, and see their training results β€” without downloading another app. This anonymized case study shows what the brief, the architecture hypothesis, the MVP line, and the 40-question discovery process actually looked like.

In my last post I argued that a WeChat Mini Program is not a translated mobile app β€” it's a new interaction layer on top of an existing global technology ecosystem. This time, a concrete case. All names, identifiers, and visuals are anonymized; the structure of the engagement is real.

The Starting Point

The client is a European manufacturer of connected gym equipment. It already operates a mature global app (Flutter, iOS/Android, about four years old) connected to its machines and cloud. But in China, users are stuck on a legacy login experience: they can sign in on the machine, yet can't properly access their results, health scores, or training programme afterwards. The China organization reported this as the single biggest source of user friction.

Crucially, the brand did not ask to port its whole app to WeChat. The brief, in one sentence:

Remove user-equipment friction and surface essential results through a simple, locally appropriate WeChat experience β€” reusing existing cloud APIs, and keeping identity, accounts, data and assets under the brand's control.

This pattern repeats across Western brands entering WeChat: a mature global product, an incomplete China experience, a strong instinct to protect data ownership, and a preference for a thin local front end over a rebuilt platform.

The Core Journey: QR Scan to Equipment Session

The whole product hangs on one handshake β€” connecting a WeChat identity to a physical machine through the QR code already printed on the equipment.

Fig. 1 β€” The QR-to-session priority flow

The machine identifies itself (serial number in the QR payload); the cloud matches user to machine; the equipment auto-configures. Every error path β€” expired code, offline machine, machine in use β€” needs a defined state in the Mini Program. For connected-hardware brands, this flow carries the entire value proposition, and its error states deserve as much design as the happy path.

The Architecture Hypothesis: A Thin Front End, Not a Fork

The proposed answer to "how much do we rebuild?" was: almost nothing. The Mini Program is a separate presentation layer speaking to the brand's existing Enterprise APIs. No access to the global app's source code is required. An optional integration layer sits in between to handle credentials, orchestration, and China-side resilience.

Fig. 2 β€” Working architecture: Mini Program as a thin presentation layer

The dashed component is the honest part: whether an integration layer is needed β€” and where it's hosted β€” depends on the API auth model, mainland-China connectivity to the brand cloud, and data-compliance requirements. It stays a hypothesis until discovery.

Here is the recurring blind spot: Western briefs almost never mention whether their cloud endpoints are reliably reachable from mainland China, where China user health data is stored, or which fields would cross the border. These questions reshape architecture, hosting, and legal scope β€” so they must be asked before any estimate.

What the User Sees

The MVP concentrates on two moments: the scan-to-session handshake, and the results view that gives users a reason to come back. Everything else β€” full programmes, video content, rich history β€” is deliberately deferred.

Fig. 3 β€” Indicative MVP screens: scan-to-session and results view

A recurring negotiation point: which proprietary visuals must be preserved pixel-exact, and which may adapt to WeChat conventions.

Cutting the Release Line

The brand's own framing helped: "the goal is not to replicate the entire app."

Release 1 β€” commit:

Later β€” defer:

One conditional rule: the training programme joins Release 1 only if the required APIs, content rights, media assets, and processing rules already exist and survive discovery validation. Conditional scope beats optimistic scope.

Forty Questions Before Any Estimate

The single most valuable artifact of the first response wasn't a design or a price β€” it was a structured information request. Roughly forty questions across six areas, each one blocking either feasibility or effort estimation:

  1. Equipment QR & session flow β€” QR payload spec, validity/anti-replay rules, full session-delivery sequence, error and recovery paths, access to a test machine. (8 questions)
  2. Identity & account linking β€” auth mechanism, WeChat-to-brand linking rules, legacy account migration, duplicates, the global identifier for cross-market recognition. (7 questions)
  3. APIs, processing & environments β€” API docs, sandbox, rate limits, cloud-vs-local logic map, and whether endpoints are reachable from mainland China. (9 questions)
  4. Product, content & UX β€” mandatory result fields, meaning of "essential history," protected proprietary visuals, design assets, language, acceptance criteria. (8 questions)
  5. China data & compliance β€” where health data is stored, which fields cross the border, consent ownership, data-subject requests, supplier security requirements. (6 questions)
  6. WeChat account & release β€” which China entity registers the Mini Program, verification status, service category, domains, and who handles review rejections. (6 questions)

Western clients often expect a quote from a brief. Experienced China partners answer with "feasible in principle" plus a complete question list β€” because the QR protocol, API auth model, and data-residency answers can swing effort by a factor of two or more.

A 1-2 Week Discovery Instead of a Guess

The path to a reliable estimate:

  1. Document & API review β€” confirm assumptions, find gaps, prioritise technical questions
  2. Product / API / engineering workshop β€” walk the full QR-to-session sequence with the brand's product owner, API owner, equipment engineer, China rep, and privacy lead, including exception flows
  3. Critical-path validation β€” actually test QR parsing, auth, session initiation, and results retrieval; a small proof of concept if the sandbox permits
  4. Scope & architecture definition β€” locked MVP, deferred scope, data flows, responsibility split, risk register
  5. Delivery proposal β€” team, effort, timeline, cost range, assumptions, exclusions, post-release support

Takeaways

They want a front end, not a fork. Mature global brands prefer a thin WeChat presentation layer over rebuilding their platform β€” control of identity, data, and assets is non-negotiable.

The physical handshake is the product. For connected-hardware brands, the QR-to-machine session flow carries the entire value proposition.

China connectivity and data residency are the silent scope-drivers. Endpoint reachability from the mainland, cross-border health-data transfer, and the registering China entity are rarely in the brief β€” and always in the budget.

Local logic is the hidden iceberg. When processing is split "roughly 50/50" between cloud and app, every locally computed feature the MVP needs must be re-exposed as an API or documented as business rules.

"Feasible in principle" + questions beats a fast quote. A structured information request, a workshop, and a short validated discovery produce a defensible estimate β€” and set change-control expectations before they're needed.