Start with the day, not the demo
Every vendor demo runs on clean data and a calm room. Your Tuesday won't. So before you score anyone on their feature grid, write down the worst twenty minutes of a normal school day — attendance during a fire drill, a parent emailing about a missing assignment, a substitute who's never opened the system. If a tool can't carry those moments, the dashboard doesn't matter.
I've watched two schools pick the exact same LMS and get opposite outcomes. The difference wasn't the software. One mapped their real routines first; the other bought on the spec sheet and spent a term working around the gaps.
What actually breaks
A handful of dull problems decide whether teachers trust the thing by October. They almost never show up in a sales call.
- Rostering. Syncing students, classes and staff from a student information system is tedious, and it's where most rollouts stall.
- Roles. Real institutions have aides, co-teachers, counselors, district admins. Anything built around two roles — teacher and student — ages fast.
- Low bandwidth. Not every kid has fast internet at home. A platform that assumes a strong connection quietly shuts people out.
- Exports. If you can't pull your data out cleanly, you don't really own it.
None of this is glamorous. All of it is the difference between adoption and a tool that sits unused after the launch email.
Build, buy, or bring in a partner
Off-the-shelf is the right call more often than founders like to admit. If what you need is common, pay for the reliable boring option and get back to teaching. You hit the wall when your model is genuinely different — an unusual assessment method, a credential nobody else issues, a data-residency rule, an integration the market just ignores.
That's the point where a custom education software development solution starts to make sense — not as a vanity build, but because the workflow you're protecting is the product. The honest version of this decision is a question rather than a pitch: is the thing you do differently worth maintaining code for, for years? Sometimes yes. Often no.
Buying for the pilot instead of the third month is the most expensive mistake in EdTech procurement.
And if you do build, scope the first release smaller than feels comfortable. One grade band, one school, one term. Ship it, watch how people actually use it, fix what hurts, then widen.
Before you talk to anyone
A short list to pin down on your own first. It'll save weeks of circular meetings later.
- Who are all the user types — including the awkward, easy-to-forget ones?
- Which systems must it talk to on day one? (SIS, payments, video, single sign-on.)
- What's your real number for concurrent users at peak — not the daily average?
- Which rules bind you: WCAG, FERPA, COPPA, GDPR? Write them down before, not after.
- What does "done" look like for version one, in plain language a parent would get?
Hand that to any vendor or dev shop. You'll learn more from how they react to it than from a polished deck full of logos.
Common questions
How long does a custom platform take?
A focused first version is usually a few months, not a few weeks. Anyone promising a full LMS by next month is selling you the demo, not the term-two reality.
Can we start off-the-shelf and migrate later?
Plenty of teams do exactly that. Just keep your data portable from the start so the eventual move isn't a hostage situation.
What's the single most common mistake?
Calm-room decisions with chaotic-Tuesday consequences. Pick for the messy middle of the term and the rest tends to follow.
One more thing
Whatever you choose, write your requirements before your first call. The clarity is worth more than any feature comparison — and it changes who's steering the conversation.