The Platform Code: How Students Open Your Academy

A course app that serves one academy can skip this entirely: the app is the academy. But most instructors do not get their own app in the store, because building, publishing and maintaining one per academy is expensive and slow.

The common alternative is a single app that many academies share. That works well, and it raises one question the app has to answer before anything else: which academy is this student signing in to?

The platform code is the answer.

What it actually is

A short identifier that belongs permanently to one academy. Every academy has its own; no two share one.

When a student opens the app for the first time, they are asked for it. The app uses it to load the right academy — the right branding, the right courses, the right account — and from that point the student sees only their academy. Everything else on the platform stays invisible to them.

It is worth being clear about what it is not, because the name misleads people:

• It is not a coupon. It has nothing to do with price, discounts or checkout.
• It is not a password or an invite. It does not grant access to anything on its own. Anyone can hold the code; only a registered student with the right email and password can actually sign in.
• It is not secret. It is closer to a phone number than a key. Publishing it is the point.

What the student experiences

The flow is short, and it is worth knowing exactly because most support messages come from one step in it.

1. The student enrols on your site. Registration happens on the web, on your own academy address, where there is no ambiguity about which academy they are joining.
2. They download the app and are asked for a platform code.
3. They enter your code, and the app becomes your academy.
4. They sign in with the email and password they registered with.
5. They stay signed in. The code is not requested again on that device.

Step one is where things go wrong. A student who downloads the app before enrolling has a valid code and no account, and the sign-in fails in a way that looks like the code is broken. It is not — there is simply nothing to sign in to yet.

Sharing it well

This is a five-minute job that quietly removes a large share of support messages, and most instructors do half of it.

Put it where students already are. The site, the enrolment confirmation page, the welcome email. Not only in one place they have to remember.

Show it with the download links. A code next to a bare app-store link is guesswork. A code next to download the app, then enter this code, then sign in with your email is instructions.

Repeat it. Students enrol weeks before they watch. The code that was in an email in March is not findable in June. Keep a short how to watch page on your site and point everything at it.

Write it the same way every time. If you show it grouped or spaced somewhere and plain elsewhere, someone will type the spaces. Pick one form and use it everywhere.

Why an app at all

The platform code exists because of a decision made further upstream: whether your courses are watched in a browser, in an app, or both.

A browser needs no code — the address is the academy. An app adds things a browser cannot do well: downloads for offline watching, notifications that actually arrive, and stronger control over how content is viewed. Whether that trade is worth it depends on your students. The mobile app guide works through the decision honestly, including the case for skipping it.

If you do offer an app, the code is part of the package, and how well you communicate it is the difference between a student who watches on day one and a student who sends a message and waits.

When something does not work

Almost every problem is one of four, and none of them need a technical answer.

"The code is not accepted." Usually a typo, or spacing that was copied from a formatted version. Ask the student to type it fresh rather than paste it.

"The code works but I cannot sign in." The account does not exist in that academy yet, or it was created with a different email address. Check the enrolment first; the code is rarely the problem.

"I am in the wrong academy." The student entered someone else's code. Signing out and entering the right one fixes it.

"It stopped asking for the code." That is correct behaviour. The app remembers the academy after the first sign-in.

For instructors choosing a platform

The code itself is a small feature, but it points at a larger question worth asking before you commit: what does the student's first day look like?

Enrolment, the welcome email, finding the app, signing in, and playing the first lesson are five steps that a platform either handles for you or leaves you to explain by hand, one message at a time. The features checklist covers what to test before you sign up — and the fastest test is to enrol as a student, on a phone, and see how far you get without help.