Learning Management Planner

The problem

An LMS built from a short prompt ends up with the same four defects:

• Course content is stored as a flat list of files. It should be a real hierarchy of modules and lessons.
• Learner progress disappears when the page is refreshed.
• Quiz scores are never linked to attempt records or feedback.
• Reports are separate counters. They should be worked out from the real learning events in the database.

The agent that built the app did not know what 38 real LMS platforms do at each decision point. It guessed, and the guesses were wrong in predictable ways.

The result is an app that can create, edit and delete courses. It passes a demo and fails in real use on the first day.

What it is built from

The planner records what 38 real LMS platforms ship, across five kinds of source:

• Live SaaS platforms for course creators: TalentLMS, LearnWorlds, Thinkific, Teachable, Kajabi.
• Open-source and academic LMS: Moodle, Canvas, Open edX, OpenOLAT, Chamilo.
• Marketplace scripts whose demos we signed into: Academy LMS, Rocket LMS, LMSZai, Faculty LMS.
• Enterprise RFPs and feature comparison PDFs.
• Discussion threads where people who run courses describe their problems.

The feature inventory gives every capability a frequency count and a tier, measured against those 38 sources.

A coding agent could guess that "course builder" and "progress tracking" matter. It cannot state that a course builder with a visible module/section/lesson hierarchy was found in 32 of 38 reviewed platforms, and that flat file CRUD is too little, unless it repeats the research. It cannot produce the exact list of 15 failure modes that marketplace scripts bring into otherwise simple builds. It also cannot produce the exact terms of the forbidden-family scan that keep marketplace features out of a Basic build: instructor payout, commission, affiliate, course approval, reviews, wishlist, checkout, coupons, Zoom, BigBlueButton, SCORM, xAPI, cmi5, OpenSesame, Skillsoft, AI tutor. That level of detail is what you are buying.

Tested in a build-off

Three coding models built three working learning-management systems from this planner: GPT-5.6 Sol, Grok 4.5 and Gemini 3.6 Flash. All three used the identical planner package, so the results can be compared directly. All three run as live demos you can sign into from this page, and the full audited ranking is published as a PlanSmith benchmark. We tested the things an LMS must get right: whether one learner can reach another learner's record, whether a completion is earned or only claimed, and whether a certificate has real backing.

What you get

One guided planning session produces a short AGENTS.md or CLAUDE.md spec file that your agent can work from (under 35 KB for a Basic build). It also produces a set of separate detail files: locked decisions, scope list, roles and permissions, data model, UI rules, workflow map, technical requirements, acceptance tests, evidence map and numbered build-step files. The planner takes you through seven structured decision blocks before it writes any of the spec.

The generated spec requires the coding agent to build a real learning product:

• Progress events that are saved and tied to completion rules.
• Enrollment records with access checks on the server.
• A record of every quiz attempt, with scores and feedback.
• Reports worked out from the source learning records, never from counters in the UI.
• A learner home dashboard that works as a "continue learning" page. A generic shell with four cards is not accepted.
• A course player that passes QA in a mobile browser before the agent marks any step done.

Every step has handover checks. The spec requires browser screenshots, proof that the console is clean, proof that data survives a refresh and a second session, RBAC probes, checks on export content, and a final readiness label (SHOWCASE_DEMO, INTERNAL_DOGFOOD, HANDOVER_CANDIDATE or PRODUCTION_BLOCKED) before sign-off.

What it covers

Phase 0 locks the Delivery Mode: Showcase demo, Internal dogfood app or Production foundation. This one decision controls whether demo auth and in-memory state are allowed, and it sets the level of proof for every later step.

Phase 1 sets the First Delivery depth: Basic (7-9 build steps, the fastest usable course platform), Moderate (10-14 steps, one or two branch families) or Advanced (marketplace, corporate compliance, SCORM/xAPI, multi-tenant or integration-heavy).

Seven decision blocks cover:

• Product and tenant model: single creator, organization, school, corporate branch or marketplace.
• Roles, and the user the product must serve best.
• Course and learning loop scope: catalog, builder, enrollments, progress, quiz-lite, assignment-lite, certificates, announcements, reports.
• Branch selection from ten families that come from the evidence: live/cohort sessions, school gradebook, corporate compliance and recertification, community and discussions, course marketplace and ecommerce, SCORM/xAPI/cmi5/LTI, native and offline mobile, AI authoring and tutor, content library and migration, SSO.
• Visual direction and primary device.
• Stack and hosting constraints.
• Build execution mode.

A required forbidden-family scan runs before the spec is generated. It makes sure that marketplace ecommerce, SCORM runtimes, live-class sessions, corporate compliance, school gradebook weighting, native app modules, AI tutor, content libraries, community moderation and gamification stay out of a Basic build unless you selected them. The build sequence then follows a nine-step template, from foundation and auth through responsive QA, security hardening and the handover audit.