What You Supply Before a Mini Program Build Starts

There is a stage of a China project that nobody warns operators about, and the obstacle in it never turns out to be technical. The quote is signed, everybody is keen, and then a fortnight goes by in which the visible progress is zero. The build has not stalled on code. It waits on a folder of things that only exist inside your business — documents, a catalogue nobody has written down in one place, and a set of policies that currently live in one person's head.

The short version: a build waits on four things, and you own all of them. Entity documents for account registration; a catalogue written out product by product, inclusions and exclusions both; the awkward policies — cancellation, refunds, deposits, weather, lead times — decided in advance instead of improvised; and named people who own the account, approve the copy and answer the first enquiry. Gather these before you sign and the timeline holds. Gather them after and the calendar moves, regardless of who you hired.

Why this is the part that slips

Development work is estimable. Somebody has built a storefront like yours before and can say roughly how long the screens take. Nobody can estimate how long it takes a five-person operator, already running a season, to produce a written cancellation policy that three staff agree on.

So the timeline you were quoted is usually honest about the build and silent about the inputs. Nobody is hiding anything; the two halves simply have different owners. The fix is boring and it works: treat the collection as a task with a date on it, the same as any other.

The documents

These go to account registration and payment onboarding, and a reviewer checks them properly; nobody skims.

Two things worth stating plainly. An overseas-entity Mini Program needs no ICP filing and no annual review — that is a requirement for websites hosted in mainland China, and it gets quoted at foreign operators far more often than it applies to them. And the Chinese name is a real decision, not a formality: it becomes the name people search, screenshot and forward, so it deserves more thought than a transliteration produced on the afternoon somebody asks for it.

The catalogue, which is the actual bottleneck

This is where projects genuinely sit and wait. A storefront is a structured thing, and structure is unforgiving: every service needs the same fields filled in, including the ones you have always handled in conversation.

For each thing you sell:

• Its name, and what a customer gets
• Duration, start time, pickup arrangement
• Who it suits and any limits — age, mobility, group size, luggage
• What is not included. The most common cause of a dispute and a recurring theme in what gets a Mini Program rejected
• Price, and how it varies — per person, per vehicle, by season, by party size
• When it runs, and when it does not
• Real photographs of the actual service, which you have the right to use

The fields are not the hard part. The hard part is that a working operator has variations that were never written down: the winter version, the thing you do for families, the price you quote when someone books two days together. All of it has to become explicit, because a screen cannot improvise.

There is an upside to the pain. Operators regularly tell us this exercise is the first time the business has been written down in one place, and the inconsistencies it surfaces are worth finding whether or not the storefront ever ships.

The policies you have been improvising

Every operator has answers to these. Few have them in a form two staff would state identically.

• Cancellation windows, and the refund at each one
• Deposit or full payment, and what the deposit secures
• What happens in bad weather, and who decides
• No-shows and late arrivals
• Lead time — the latest a booking can come in
• Changes: date moves, name changes, party size

These have to be decided because they are published. A Chinese storefront states terms before payment rather than after, and a policy invented per-customer becomes visibly inconsistent the moment two people compare screenshots.

The people

Three roles, and a build slows down when any of them is unnamed.

Who owns the account. Which entity holds the registration, and who keeps the credentials. Settle it at the start, before it becomes a discovery, for the reasons in whose name the account is actually in.

Who approves the copy. One person, not a committee, with enough authority to say yes. Chinese copy that circulates for consensus loses a week per round and comes back blander.

Who answers the first enquiry. A storefront produces questions on day one. Someone has to be able to reply in Chinese, in a window you can actually keep.

What you do not have to supply

Worth listing, because these are the things people assume and then delay over.

• A Chinese company. An overseas entity can register and operate.
• ICP filing. Covered above; it does not apply.
• Translated copy. Sending a Chinese translation of your English site is usually wasted effort — the text is rewritten for a different reader, not converted. That distinction is the whole of why translating the website is not a China strategy.
• A finished photo library. Real and ordinary beats polished and generic. Phone photographs of the actual vehicle, room or plate are more useful than a stock set.
• Every product. Launch with what you are confident about. A catalogue grows.

An order that does not stall

Start the documents first, because they are the ones with a queue in front of them — review sits outside your control and outside ours. Write the catalogue second, in parallel, since it takes the longest and only you can do it. Settle the policies while the catalogue is in progress; they tend to resolve faster once the products are written out. Name the three people on day one, which costs nothing and prevents the most common late-stage delay.

Where CN1X fits

We send the list, chase it, and turn it into the storefront — the account registration, the catalogue structure, the Chinese rewriting and the review submission all sit in what we build. The collection is the half we cannot do for you, so the useful thing we can offer is a specific list rather than a vague request, and a straight answer about which items genuinely block the timeline.

If you are weighing a build and want to know what the preparation would actually demand of your team before committing to anything, ask us for the list first.