Case study — learning tooling
I turned a raw script into a brand-compliant, review-ready course — automatically.
An AI-assisted production pipeline that collapses multi-day eLearning builds into a near-automated workflow. Designed and built solo, from scratch.
Who's looking?
A one-person build that automated the slowest, most error-prone part of course production.
Tools & skills
What it proves
I can scope, design, and ship production tooling independently — not just author content, but build the system that produces it.
Three choices that show how I think about systems, risk, and the people using them.
The tradeoff I made
The framework cost real time up front before it saved a single hour. I bet on compounding return over one-off speed — and knowing what I know now, I'd make that call again.
The architecture — content treated as a build, not a document.
I stopped treating courses as documents and started treating them as builds: versioned components, a spec the system enforces, a real review loop.
Prefer to read the whole thing?
The full case study, start to finish.
The problem
Manual eLearning production is slow and inconsistent. Every new course re-litigates the same interactions from scratch, brand drift creeps in the moment a designer looks away, and review happens across scattered threads with no clean way to hand notes back to whoever's building. It's a lot of skilled time spent on work that shouldn't need a human every time.
What "good" had to mean
- On-brand output with no designer babysitting the result.
- Interactions built once as reusable parts, never re-solved per course.
- Non-technical reviewers can approve or reject without touching code.
- Edits round-trip cleanly back into the build environment.
What I built
An AI-assisted production framework, built in Cursor. A script goes in; a brand-compliant, review-ready SCORM course comes out. Under it sits a library of interaction primitives (originally hand-coded in HTML to do what off-the-shelf tools can't), a machine-readable brand and UI spec the generator is bound to, and an Apps Script review portal that packages the course, routes it for approval, and feeds comments back to the developer backend.
Key decisions
Guardrail as code. Rather than trusting a style checklist, I made the brand system a spec the generator has to obey — so off-brand output isn't a mistake that can happen. Primitives over one-offs. Solving each interaction once meant the system got faster and more consistent with every course. Review without code. The approval loop was designed for the people who sign off, not the people who build, which took the dev team out of the bottleneck.
Impact
Multi-day manual builds collapsed toward same-day output, brand consistency became automatic instead of hand-policed, and course review stopped waiting on developer availability. More to the point: it moved the team's skilled time off assembly and onto the parts that actually need judgment.