I didn't set out to build a product. I was sitting in on a meeting between a school head and their technologist, reviewing how they tracked student progress under their Mastery Learning approach. What I saw was Excel — spreadsheets tracking hundreds of students against dozens of outcomes, rebuilt by hand every year, with no protection against a deleted row erasing a semester of work.

Four things stood out immediately. Finding the right cell — the intersection of the right student and the right outcome — was slow and error-prone once a class extended past a single screen. Every new entry overwrote the last, so nobody could see how a student actually progressed, only where they currently stood. And the tool only spoke to teachers — under Mastery Learning, where students are supposed to know exactly where they stand and administrators need to see where a whole cohort needs support, that was a real gap, not a minor one.

Two more conversations, around the same time, confirmed I wasn't looking at one school's problem. Another school had abandoned letter grades entirely in favor of written narrative summaries — different mechanism, identical goal: show a student what they're learning and where they can grow. And closer to home, my wife was part of a group of teachers at traditional high schools incorporating Mastery Learning into their own curriculum, all facing the same open question with no good answer: how do you actually track this?

So I built one. Not for a client — for the problem itself. Outcomes lived in a real data model, not a spreadsheet: assignable per student or per class, evidence-based rather than overwritten, and visible to the people who actually needed to see it — including, for the first time, the students themselves.

Building the system was the easy part. Getting people to actually use it the way it was designed to be used was harder. Teachers, buried under everything else on their plate, tended to enter observations in a single deadline-driven session rather than spread out over the term. Working that way, they forgot the bulk-entry tools existed and complained about how long it took — a training problem on the surface, but really a motivation problem underneath. If regular entry wasn't obviously worth their time, no amount of training was going to change the pattern. Some of the dashboard views exist specifically because of this — they gave teachers a reason to log in between deadlines, not just before one.

Administrators surfaced a different challenge entirely. The system pushed them toward defining outcomes more precisely and aligning them across the curriculum — which was the point. But that precision came with a side effect: a steady stream of requests for more fields, more nuance, more ways to describe a single outcome. My instinct was to accommodate every one of them. It took a step back to recognize what was actually happening — I was watching one organization's specific preferences slowly turn into scope creep that wouldn't mean anything to any other school using the platform. Saying no to some of those requests was harder than building the feature would have been.

The same data model built to be configurable from day one turned out to be what let the platform absorb these lessons rather than needing a rebuild. The dashboards, the pushback on scope creep, the adjustments that came from watching real use unfold — all of it fit inside the same architecture, refined rather than replaced. It took a few years of that kind of real-world refinement for Luma to mature into the version I was genuinely proud of. It was that matured version, not the first release, that was later showcased at a prominent national education conference.