What a school actually needs from a learning platform

Most academies come to me asking for "a website." What they usually need is a platform — something that markets the school, brings students in, and supports them once they're there. The gap between those two things is where a lot of money gets wasted.

One academy I built for, Future Meds, came to me wanting a site that would rank on Google and show them off properly, so they could get students' attention. A fair goal — but their old site was working against them. It wasn't built for search, it looked rough, and honestly it was half-broken: dead links, a different navbar on nearly every page, sections that were never finished. It didn't reflect the quality of the actual business. By the end, they didn't just have a better-looking page — they had a system they run themselves. Here's how I'd think it through before you spend anything.

Start with the job, not the features

A learning platform exists to do three jobs: win enrolments, deliver the course, and let your team run it without a developer. Every feature should ladder up to one of those. If it doesn't, it's a distraction — however impressive the demo looked.

The parts that actually matter

• A presence that reflects the business. Prospective students (and their parents) judge you in seconds. From the start, I saw Future Meds' problem as bigger than a page — a school's site is its business reflected online, so it has to be fast, credible, and clearly theirs.
• A team that runs it themselves. Their staff now manage almost everything through an admin panel — courses, news, the gallery, previous-year question papers, university details, the blog. Add a new course, post an update? They just do it. No developer in the loop.
• Something students actually use. The feature everyone rallied around was doubt sessions: a student books a slot, a teacher spins up a meeting and works through it with them. Small thing, big signal.
• Being found. SEO isn't a nice-to-have for a school; it's an enrolment channel. It has to be built in, not bolted on.

The detail that did the convincing

Not everything worth building is on the brief. For Future Meds, every past doubt session shows up on a public calendar right on the website — open proof that the academy actually shows up for its students, sitting there for any prospective student to see. It wasn't something anyone asked for; it just made sense. I hadn't seen another academy do it, and it quietly became one of the most persuasive things on the site.

The lesson: the most convincing feature is often the one that turns work you already do into visible proof.

Build vs. buy

Off-the-shelf tools (Teachable, Moodle, and friends) are great when your process fits theirs. The moment you need your own enrolment flow, your own branding, or a feature they don't offer, you start paying in workarounds. Future Meds never wanted a prebuilt tool — they wanted a free hand to shape the platform around how they actually work, so custom was the right call. If your process is more standard, off-the-shelf might be smarter. I'm happy to tell you honestly which side you're on.

The question to ask any developer

"When this is built, can my team run it without you?" If the answer is no, you haven't bought a platform — you've bought a dependency. Future Meds can manage their courses, content, and doubt sessions themselves; I built it, but they own it. That's the whole point.

---

If you're weighing this up for your academy, tell me what you're building — I usually reply within a day.