Building a member app before every feature is live

Pre-launch products have an awkward job. They need enough shape for people to understand them, but they should not imply that a checkout, community, or partner catalog is already operating when it is still being built. A website can collect interest. A mobile app can show the intended experience. The admin team needs a place to prepare content. Keeping the boundary between those states clear is part of the work.

We saw that tension in a member platform with a Next.js website, an Expo mobile app, and shared design tokens. The public site runs the launch and waitlist experience. The mobile app carries navigation for shopping, community, account, and order journeys, with demo data in flows awaiting live integration. The admin side handles content and access. The architecture connects those surfaces without claiming they are all at the same maturity.

One brand, different devices

Sharing color, spacing, and type tokens is less dramatic than sharing every component. It is also more useful. A web menu and a native tab bar should not be forced into the same shape, but they should feel like the same product. A small shared token package gives designers and engineers one reference while leaving room for each device's interaction patterns.

The same principle applies to data. The site and app can share an identity system, while privileged admin operations stay server-side. A member's account is not an admin account just because both use the same sign-in provider. The role check is explicit, and the service credentials do not travel to the browser or phone app.

A waitlist is a real workflow

“Coming soon” pages are often treated as disposable. In practice, the first operational questions arrive there: did a person sign up, did a confirmation send, can the team review messages, can someone unsubscribe, and is the page discoverable at the right time? The platform includes a waitlist, contact messages, admin review, email, and a deliberate noindex setting while the launch site is not ready for search traffic.

That last choice is easy to miss. SEO does not always mean asking search engines to index everything immediately. Sometimes the honest move is to keep a pre-launch experience out of the index and publish a complete, useful page when there is something real to find.

Mark the seam between demo and live

We like demo data when it lets a team test a flow and discuss the shape of a product. We dislike it when it looks indistinguishable from a promise to a customer. The seam should be visible to the builders and clear to the people evaluating the product. That makes a phased launch more credible, and it keeps the next integration from becoming a surprise rewrite.