Open-source EdTech: build around the school day, not another dashboard

Start with the handoff between people

An admissions officer accepts an application. Someone creates a learner record. A teacher needs the right class list. Finance needs the agreed billing information. Each handoff is an opportunity to lose context or give someone more access than the task requires.

Before choosing an LMS or commissioning custom school software, map that journey with the staff who actually do the work. Record who owns the information, which system is authoritative and what must happen when a record is corrected. A polished dashboard cannot resolve competing versions of the same learner.

Open source creates options, not an operating team

An open-source platform can offer room to inspect, adapt and maintain software. Its licence, deployment model and integration surface still need review. Hosting, upgrades, backups, support and staff training remain someone’s responsibility.

Moodle’s web-services documentation offers a useful starting point for assessing integration possibilities. An available interface is the beginning of an integration plan. You still need to define permitted operations, credentials, failure handling and a way to reconcile records after an interruption.

For a school evaluating options, ask for a demonstration of one complete workflow using fictional records. Can a team member correct a mistake? Can an administrator revoke access? Can another supplier take over maintenance without reconstructing the whole system?

Connect the useful part before replacing everything

A focused integration may solve the immediate problem without replacing a working teaching environment. For example, an application intake flow might need to create a draft record for review while the established learning platform continues to run classes.

That example is a planning pattern, not an announced Skolr connector. The distinction matters: a roadmap diagram should not be mistaken for a shipped integration. Agree the first workflow, its acceptance conditions and a rollback route before expanding the scope.

Put AI permissions in the workflow

The product direction behind Skolr separates questions, proposed changes and approved actions. Those moments need different permissions. A teacher preparing material should not gain admissions or finance access because the same assistant can answer both kinds of question.

For any education AI proposal, make the review screen specific: which record will change, who can approve it and how the team can see what happened. Use synthetic records while validating boundaries. A fluent answer is not evidence that an action was authorized.

What to put in an EdTech brief

Describe the school’s roles, the first workflow, existing systems and the records that must move between them. Include accessibility, language needs, support ownership and an exit plan. For Toronto, GTA and other Canadian education teams, those operational details are more useful than a long feature wish list.

Our Skolr case study shows how these concerns shape a private-beta product. It is a starting point for a practical conversation about school operations, rather than a promise that one platform should replace every tool a school already uses.