Verify the Business Before It Goes Live: Onboarding Design for a Walk-In Services Marketplace

A queue app for barbershops and salons sounds simple: show customers how busy a shop is and let them join the line. When we designed one as an in-house product, the question that mattered most was which shops should be allowed on the platform at all. The first release includes an onboarding flow that verifies every business before it goes live.

The product

The app is a mobile queue and appointment tool for walk-in service businesses:

• Customers see real-time seat and queue status for each shop.
• Stylists are assigned to customers.
• Each shop runs its own loyalty points, with a configurable conversion rate.
• Every store goes through onboarding that verifies it before it goes live.

It is built with React Native and Expo on mobile, and Node.js, Express and MongoDB on the backend, with a Swagger-documented REST API.

Why verification comes first

A two-sided marketplace has a trust problem on both sides. Customers need to believe a listed shop is real and operating. Genuine shops need to believe the platform is not full of fake or abandoned listings that make it look unreliable.

Checking businesses after they are live is reactive: a bad listing has already been seen by customers. Checking them before they go live is a design decision, and it is far cheaper to build in at the start than to add once a marketplace is full of unverified listings.

What the onboarding flow collects

Store onboarding in the app asks for:

• A business licence, so the shop is a legitimate business.
• Photos of the shop, so customers know what to expect and listings are real.
• The owner's ID, so a real, accountable person stands behind each store.

A store goes live only after verification. That step adds friction for shop owners, which is intentional. The small effort filters out listings that would damage trust for everyone else.

Model the real business, not a single user

A barbershop is not one person. The app models roles per store, with stylists and receptionists as separate roles. That matters in daily use: a receptionist manages the queue, a stylist sees their own customers, and the owner controls the store.

Building a marketplace around a single "business account" is a common early shortcut. It breaks as soon as a real shop tries to use it with more than one member of staff, and fixing it later means reworking permissions across the product.

Make each shop's rules configurable

Loyalty points are configurable per shop, including how points convert. Different businesses price and reward differently, and a platform that forces one rule on everyone makes itself less useful to the businesses it depends on.

The general principle: where businesses on your platform differ in how they operate, make that a setting rather than a hard-coded rule.

Design subscription status in from day one

The business model is a subscription paid by shops, so each store carries a trial-to-paid subscription status from the first release. Designing monetisation in from the start means:

• The product can test whether shops will pay, which is the real question for this kind of marketplace.
• There is no disruptive migration later to introduce billing states into every store.
• Features can be tied to subscription status cleanly.

If customers will pay in several countries, billing gets harder quickly; our notes on billing across 15+ payment gateways cover that case.

What this means for your marketplace

If you are planning a two-sided marketplace for local or walk-in businesses:

• Decide what proof a business must provide before it appears to customers.
• Model staff roles inside each business from the start.
• Turn operating differences between businesses into per-business settings.
• Build the billing status into the data model in version one.
• Document the API as you build it, so mobile and backend stay in step.

The anonymised write-up is in our work library. Matching is the other half of most marketplaces, covered in designing a weighted matching engine. For another early decision that marketplaces cannot easily change later, see building the account foundation first. Scoping a first release around the riskiest assumptions is how our MVP service works.