Software should arrive ready, not empty.

Every institution that has bought a learning management system knows the moment after the contract is signed. The platform is live, the logins work and there is nothing in it. What follows is a multi-year effort to fill it: course shells, outcome statements, rubrics, prerequisites, program maps, accessibility checks and the hundreds of small decisions that turn a set of courses into a program.

None of that work is wasted, but very little of it is new. A nursing program in Ohio and one in Oregon answer to many of the same standards. A district adopting new state math standards is doing what dozens of districts did before it. A workforce agency mapping a training program to in-demand jobs draws on the same labor-market data as its neighbors. Yet each of them starts from a blank page, because the software they bought was designed to hold structure, not to bring it.

Three ways institutions get stuck

In practice, teams choose among three imperfect options.

The empty box. A capable platform that does exactly what you configure it to do, and nothing until you do. The burden of structure falls on faculty and instructional designers, who rarely have time to do it twice.

The closed box. A publisher’s library that arrives full, but full of someone else’s decisions. It’s hard to adapt to your requirements, hard to align with your outcomes and hard to take with you when you change systems.

The fast box. General-purpose AI tools that can produce a syllabus in seconds. They’re genuinely useful for a first draft. But they know nothing about your accreditor, your prerequisites, your learners or your voice, so every draft has to be checked against all of those by hand.

Each option solves part of the problem. None starts where institutions actually start: with intent. What is a program for, who does it serve, what must it satisfy and what does it promise?

Structure first

We think the order should be reversed. Before anyone writes a lesson, the platform should already know the territory: the academic domains a program draws on, the standards and regulatory frameworks that apply, the programs elsewhere that do something similar and the occupations they lead to. Then an institution’s teams spend their time on the part only they can do, shaping that structure to their mission, their learners and their voice.

This doesn’t remove choice. A program that starts from a well-organized map still makes every decision that matters. It just doesn’t have to rediscover the shape of the field before it can make them.

What changes when software arrives ready

• Launches get shorter. When requirements, curriculum and approvals are built from the same structure, they stop moving through separate documents and separate teams. The slow part of a launch is rarely writing. It’s reconciling.
• Curriculum stays current. When a course is connected to the standards it was built against, a change to those standards becomes a specific, visible task instead of a surprise at the next review.
• AI becomes safer to use. A drafting tool that works within an institution’s own structure produces drafts that already respect its requirements. Faculty refine instead of rewriting.
• Systems become interchangeable. When the structure belongs to the institution rather than to one application, the LMS, the AI assistant and whatever comes next can all draw from the same source.

The question to ask

The next time your institution evaluates learning software, ask a simple question: on the day we go live, what will this already know about what we teach? If the answer is “nothing until you tell it,” you’re buying a container, and your teams will be the ones filling it.