Architecture choices become expensive when they are discussed only in diagrams. For a product already shipping on the web, Android and a WeChat mini program, I prefer a narrow technical spike with real code and real devices.

Define the contract first

The current product is the baseline for page structure, copy, assets, interaction flows and state recovery. A spike is not permission to redesign the application. It answers one question: can a proposed architecture reproduce the product while improving maintainability and runtime quality?

Test representative flows

I choose a small set of flows that expose the hard parts:

  1. navigation and page state restoration;
  2. authenticated API requests and error handling;
  3. audio recording or playback;
  4. local storage and background behaviour;
  5. a release build running on a physical device.

This is more useful than porting dozens of easy screens. If the architecture cannot support the difficult platform boundaries, a larger migration only produces more code to undo.

Share decisions, not assumptions

The target is one source of truth for product behaviour, data models, copy and design tokens. Platform-specific code should be explicit and thin.

shared product rules
        ↓
shared data + state
        ↓
platform adapters
        ↓
web / mini program / native

The final decision should be backed by build output, device measurements, a list of unavoidable differences and a clear rollback path. A successful spike reduces uncertainty; it does not need to become the production migration itself.