Launch playbook
Eight things, in this order
The first three decide whether it happens at all. The last five decide how long it lasts.
01
Cut scope before you build
A first release with all twelve modules usually dies of neglect. Open the feed, the tree hole and events; enable email verification only. Add the marketplace, course reviews and matching once daily usage is steady and moderation keeps up.
The test isn't "is the feature finished" — it's "is there someone who can deal with a problem in it within two hours".
02
Apply for the accounts first — they're slower than the code
Prepare a mini-program account, a storage bucket and a sending mailbox. Add a merchant account for top-ups. Mini-program release review and merchant verification take time.
The released mini program must include the QR confirmation page and have AppId/AppSecret configured.
03
Deploy and migrate
Get MySQL 8, Redis and JDK 25 ready and put the credentials in the environment. Run the schema and migration scripts before starting; startup validates the configuration and tells you exactly what's missing.
Run every migration segment. A skipped one doesn't error — it produces "the action succeeded but nothing changed", which is far harder to trace.
04
Configure the school
Create the school, its faculties and its campuses, then decide which verification routes it opens. If you enable the quiz you need questions first — the bank is per school, single and multiple choice both work, and you set how many correct answers pass (blank means all of them).
If there aren't enough live questions for one quiz, that route reports itself unavailable rather than borrowing from another school. Walk the whole flow yourself before launch.
05
Fill the homepage before anyone sees it
The carousel, shortcut grid, daily poem, topics and homepage tabs are all configured in the console. Deep links are validated against the page registry, so a wrong path won't save.
New entries start unpublished. Configuring one isn't the same as turning it on.
06
Staff a moderation rota
At least two people, with verification review and report handling on the calendar. Rejection reasons must be specific — they go to the student verbatim, and a vague one comes back as a resubmission tomorrow.
If someone already handled an item, the console says so — you won't get two people judging the same thing.
07
Seed it: content before people
Nobody wants to speak first in an empty room. In the week before launch, have your team and the clubs fill it: a few dozen tree-hole posts, two or three events, a batch of listings. The first real user should arrive somewhere that's already running.
Open one faculty or one campus first, not the whole school. A small blast radius makes early problems small too.
08
Once it grows, delegate
Campus admins can create their own operators and moderators; clubs can be handed an admin scoped to exactly their one club. One person moderating an entire school doesn't survive a semester.
A club admin can't see other clubs, and can't see other schools — so delegating authority isn't the same as opening up the data.
Multiple campuses, multiple schools
These two get conflated constantly, and they are handled completely differently.
One school, several campuses
A campus is a first-class entity, and geography hangs off the campus rather than the school — two campuses of the same school sitting in two districts is the normal case. The "my campus" and "my district" ranges resolve against that structure. Users pick their campus; they can't pick their school, because the school comes from verification.
Several schools on one deployment
Supported. Each school gets its own campus admins, its own quiz bank and pass mark, and its own content boundary. Cross-school access returns "not found" rather than "forbidden", so an admin can neither see nor probe what another school has. Site-wide content — a global topic, say — is maintained by super admins and read-only to campus admins.
Pre-launch checklist
Every credential comes from the environment; none are written into a config file
Every migration script has been run, with no segments skipped
You have walked the whole path: sign up → verify → post → comment → report → resolve
Storage CORS rules are configured and a client can genuinely upload
Someone is on the moderation rota and reports are actually seen
The privacy policy and terms are reachable inside the app
Mini-program page paths match the registry in the console
Mistakes other people made first
Launching without walking the verification flow
Verification is the first door a new user meets; if it jams, the whole site jams. Walk it end to end with a brand-new account before launch, including a rejection and a resubmission.
Writing "does not meet requirements" as a rejection reason
The student reads that sentence and resubmits exactly the same thing. Say what's missing and how to fix it, and you'll halve the repeat reviews.
An empty homepage on launch day
Placements start unpublished and there's no seed content, so the first cohort arrives at a ruin. They don't come back for a second look.
Only one person has a console account
The day they're busy, moderation stops. Add the second person on day one.