What Order Should Your Mini Program Actually Handle

A cleaning company owner came to us and said he wanted a mini program. We asked which order he wanted it to handle. He paused, then said, the kind where people place orders.

That pause is the whole problem.

Most local owners start with a picture in their head. What the home screen looks like, how many buttons, whether there are coupons or a points store. Almost nobody starts with the question of which step the thing is supposed to remove.

So it launches, and customers still phone in. Technicians still take jobs in a group chat. The front desk still writes in a notebook. The app becomes a decoration on the storefront, and twenty thousand buys an icon nobody taps.

This article is not about whether to build. It is about what to settle first. Get this right and the design, the budget and the timeline all fall out of it.

A note on context. We build on WeChat mini programs, which is the default app surface for local commerce in China. But the decision framework below is not specific to WeChat. It applies to any booking, dispatch or ordering app you are about to commission, whether that is a native app, a web app, or a mini program.

Four fulfilment types, four different builds

Local service orders split by how they get fulfilled, and each type has one module that actually matters.

Find your row first. It decides where the money goes.

One caveat. Plenty of businesses are mixed. A salon does both in-store and home visits. A restaurant does dine-in and delivery. Build the dominant type in version one and add the second later. Trying to cover everything at once is the single most common cause of a slipped launch date.

Three mismatches we see over and over

Home service built as a storefront. Product cards everywhere, variants, prices, a cart, but nothing about who shows up or when. An order lands in the backend with nobody assigned to it. Two hours later someone from customer service notices, by which point the customer has already called to complain.

On-site visits built as booking only. Redemption still happens on paper. Balances, prepaid visit counts and purchase history live in a notebook, so the app and the shop keep two sets of books that never reconcile at month end.

One location built as a platform. A single shop insists on headquarters, branch, manager and staff roles. Permission logic gets rewritten four times and version one is still not live three months later. Right now your business has one role, and it is you.

Three questions to answer before you brief anyone

Answer these and every conversation with a developer gets easier. If you cannot answer them, do not request a quote yet.

1. How do orders reach you today. Phone, group chat, a marketplace, a paper log. Write it down.

2. Which step is the app meant to remove. Removed, not added. Anything that adds a step for the customer ends up unused.

3. Who runs it after launch. Who brings customers in, who watches the dashboard, who handles exceptions. If the answer is nobody, do not build it.

A brief template you can copy

Do not send a developer "I want an app where people can order." Ten agencies will give you ten quotes, from eight thousand to eighty thousand, because nobody knows what you actually mean. That spread is not greed, it is ten different assumptions about complexity.

Write five blocks instead. Copy this and change the numbers.

We are a (trade) business with (X) (locations / technicians / rooms / instructors).
Customers currently book via (phone / messaging / marketplace / front desk), and (who)
assigns work manually.

We need the app to do three things.
Customer   can (choose a service / pick a time / enter an address / track status).
Worker     can (accept a job / reschedule / mark complete / see today's route).
Admin      can see (all of today's jobs / counts per status / exception alerts).

In version one   the core job loop only.
Not in version one   (referrals / points store / multi-city / livestream).

Systems to integrate   (none / messaging account / payments / existing ERP).
Target launch   (date).

That tells a developer three things. How many roles there are, how a job moves between states, and what version one explicitly excludes. Quotes that come back from a brief like this usually land within twenty percent of each other.

Budget and timeline, three rough tiers

These are observed ranges for custom work in China, not a price list. City and team vary a lot.

Price tracks role count and state complexity, not screen count. Three or four roles with seven or eight job states will always cost more than a twenty-screen brochure app, even though the brochure app looks more impressive in a demo.

Build versus buy, honestly

If you operate in North America or Europe, the honest answer for many single-location trades is to buy first. Jobber, Housecall Pro and ServiceTitan cover dispatch and invoicing for field services. Square Appointments, Acuity and Fresha cover booked slots for salons and studios. Monthly cost runs roughly USD 30 to 300 per user, and you can be live in a week.

Buy when your process matches the tool and you do not need to own the customer relationship. Build when your dispatch rules are genuinely specific, when you need the customer data in your own system, or when you are operating in a market where those tools do not exist, which is the case for WeChat-based businesses.

The trap is in the middle. Buying a template and then paying for a year of customisation usually costs more than building the thing once, and you still do not own it.

Version one scope

Get one job from start to finish. Request, assign, perform, collect, review. That is the whole loop.

Everything else waits. Points store. Referral programme. Livestream. Multi-city. Member tiers beyond three levels. Coupon stacking rules.

None of these are bad ideas. They are bad ideas for version one. Adding marketing features before the core loop works is pouring water into a leaking bucket.

Getting people to actually use it

An app that launches to silence usually has an entry point problem, not a product problem. Three cheap fixes.

Put the code where the customer already is. Table tent, counter, receipt. A customer standing in your shop is the easiest person to convert.

Link it from the channel you already own. Your messaging account menu, your email footer, your Google Business Profile.

Tell existing customers once. Not an ad. One line. Next time you can book here directly, no need to wait for my reply.

And the one everybody forgets. Exceptions. What happens when a technician runs late, when a customer wants to move the slot, who authorises a refund. None of this shows up in a feature list, and all of it decides whether there is a second booking.

Approvals, payments and what they cost you in time

Start these in parallel with development, not after it.

On WeChat, the service category must match what you actually sell, or submission is rejected. Healthcare, education and financial services need sector licences. Online payment requires a business entity and a corporate bank account, personal accounts cannot enable it. Location access needs a declared purpose.

App stores have their own version of this. Apple requires an entity enrolled in the developer programme and asks for a privacy manifest describing what data you collect.

Rejections here cost one to two weeks on average and have nothing to do with your developer's skill. They are the most common cause of delay in local service projects.

Two more things if you serve Western markets. Card data means PCI scope, which in practice means using Stripe or a comparable processor and never touching raw card numbers. If you hold customer data for EU or California residents, you need a stated retention period and a way to delete on request.

FAQ

We have one location. Do we need an app at all?

Depends on the problem. If customers cannot remember your number, bookings live in your head, and you cannot tell a regular from a first-timer, then yes, one location is enough reason. If your problem is that not enough people walk in, an app will not fix that. That is a demand problem, not a tooling problem.

Can we start cheap and upgrade later?

You can, but know the cost. Template products usually have a fixed data structure. Once the business runs on it and you want to move to a custom system, historical records often cannot be exported, which means rebuilding. If your process is standard, the template is fine. If you intend to own the customer base long term, pick something that lets you export from day one.

What is the difference between the messaging account and the app?

The account handles content and reach. The app handles transaction and service. They can link to each other and share one customer identity. For most local businesses the working combination is content in the account, ordering and membership in the app, one identity across both.

Will this help us avoid marketplace commission?

That is the real motivation for most owners, so look at the full picture. Running your own channel does remove order commission, leaving only payment processing at roughly 0.6 percent in China or 2.9 percent plus a fixed fee on Stripe. The trade is that you now own acquisition and fulfilment, and those costs frequently exceed the commission you escaped. Do that arithmetic before you decide.

How long until we see results?

Build takes four to eight weeks for a standard custom job. Results depend on operations and usually need three months or more. The number to watch in month one is not order volume, it is what share of existing customers used it once. Around thirty percent means it is working.

Want a second opinion on your brief

Fill in the template above and send it over. We will tell you three things. Which order type your business actually is, what version one should cut, and a realistic budget and timeline range.