Start with the student. Ship the engine everywhere.

The gap we kept seeing

Technology in education often moves slowly—and budgets tend to flow toward advising and administrative workflows first. That work matters. But it is not the same as giving every student a credible, verifiable path through a degree when life changes, a course is not offered, or a prerequisite breaks.

Some products have moved in a more student-centered direction. Even then, much of what ships still looks like warnings and buckets: put a course in the wrong bucket and you get a flag. The student is still left to trial and error across term offerings and prerequisite chains. When circumstances shift, the puzzle has to be re-solved by hand—and advising is human capacity. On many campuses advisors are outnumbered hundreds to one, so reactive plan repair does not scale.

Even the strongest tools in the space tend to generate a plan from a limited set of global assumptions, then function more like an interactive template once the student starts making changes. A student may be able to move a course and see whether the plan still validates, but that is different from telling the system: cap this specific term at two classes, allow only one lab in the summer, avoid these two courses together, or apply a conditional rule like, “If physics and biology land in the same term, cap that term at two classes because I cannot handle more than that.”

That is the level of planning students actually need. Not just a recommended schedule. Not just a validator. A system that can accept real constraints and rebuild the plan around them.

What we chose to build

Our mission is to start with the consumer first—the student—and ask what a perfect outcome would look like. Before choosing the interface, the platform, or the technology, we worked backward from the actual problem students face: they need to express real-life constraints, get back a plan that is feasible against the catalog, and be able to pressure-test that plan when something fails, moves, or disappears from a term.

That meant we could not simply build another planning screen and hope it improved the experience. A static plan is helpful until reality changes. And for most students, reality changes.

We did not set out to compete with incumbent SIS screens or replace every planning UI. To get this capability to as many students as possible, we built a headless API engine that accepts structured program data and freeform constraints, parses those constraints into a formal model, and solves the plan combinatorially—not through trial and error and not improvised by a language model.

Partners embed it inside their own experiences so students can describe circumstances in natural language while the outcomes stay deterministic.

What “good” planning includes

The engine is designed around research-backed realities you will also see in our Research section—such as the leverage of gateway courses and the damage when seasonal offering windows are missed. We prioritize recoverability and buffers where the graph is fragile, and we support what-if and stress scenarios, such as a course not offered or not passed, so students and advisors can see consequences before they commit.

Good planning should not only answer, “Can this course go here?” It should also answer, “What is the best path from here, given everything the student is trying to balance?”

That includes hard academic rules, student preferences, term-by-term limits, course pairing concerns, seasonal availability, failed-course recovery, major-change exploration, and constraints that do not fit neatly into a traditional planning screen.

Not an LLM wrapper

Large language models are useful for language, explanation, and UI—but they are not a substitute for an engine that can search a huge discrete space under hard rules.

PlanMyClasses is built around a proprietary planning engine infrastructure designed for academic logic, with structured JSON inputs and outputs so platforms can integrate without adopting our front end. Natural language can help students describe what they need, but the final plan has to be generated by a deterministic engine that understands requirements, prerequisites, offerings, sequencing, and constraints.

That distinction matters. A student should not receive a confident-sounding plan that only appears correct. They need a plan that can be checked, explained, and trusted.

What we hope institutions see

When students can see a path that fits their life—and replan quickly when reality changes—we expect stronger persistence and fewer silent drop-offs from pathway paralysis.

When a student considers a new major or minor, an advisor can mark what is already satisfied and hand them a program definition; the student can explore many what-if schedules without burning down advising hours.

When a course is not offered, a student fails a class, or a personal constraint changes their availability, the system should not leave them with a broken template. It should help them find the next viable path forward.

That combination—scalable, integrable, and constraint-rich—is the capability we are working to make normal.

For a buyer-oriented view of the problem space, see Institutional impact; for scripted UI patterns on top of the engine, see Partner demos.