Cuegence Postmortem — Part I: I Fell in Love With the Engineering Problem

Part 1 of the Cuegence postmortem — a three-part account of a startup that was killed ten days after it was imagined.

Ten days ago, I started thinking about a problem in education.

Ten days is worth stating up front, because everything in this series — three product definitions, several market pivots, six customer conversations, and a kill decision — happened inside that window. How that was even possible is a story for later. First, the problem.

Schools have marks. They have attendance, report cards, examinations, assignments, homework, teachers’ observations, and increasingly some form of LMS or ERP. But almost all of this is episodic.

A student gets 42/50 in a mathematics test. Three months later, they get 31/50. Somewhere between those two numbers, something happened. Perhaps they never properly understood fractions. Perhaps they understood them and forgot them. Perhaps a prerequisite concept was weak. Perhaps a teacher intervened and it worked for a while. Perhaps the examination simply happened to contain questions they were comfortable with.

The school stores the two marks.

It doesn’t store the learning journey between them.

That became the seed for Cuegence.

The core idea was to build a longitudinal model of learning: a continuously updated representation of what the available evidence suggests a learner understands, where uncertainty remains, what they may have forgotten, which prerequisite concepts might be causing trouble, and whether previous interventions actually helped.

Not an AI chatbot for students. Not another LMS. Not another dashboard showing average marks by section.

A learning-intelligence layer.

And as an engineering problem, it was beautiful.

A note on “we”

You’ll see “we” throughout this series, and I owe you an honest definition. The “we” was me, Claude, and ChatGPT, with Grok occasionally auditing the analysis. One human, several very patient language models.

This is also the answer to how ten days was enough. Product definitions that would once have taken me weeks of solitary drafting went through multiple adversarial revisions in an afternoon. Every market pivot got stress-tested the same evening it was proposed. The models didn’t have the ideas or make the decisions — but they compressed the loop between having a thought and seeing its weaknesses from days to minutes.

That deserves its own essay. For now: assume every “we” below is me plus machines, and every mistake is mine alone.

The rabbit hole opened very quickly

The first obvious requirement was a curriculum graph.

A textbook might be organized into chapters, but learning doesn’t really happen as isolated chapters. Concepts depend on other concepts. You cannot properly reason about algebra if arithmetic foundations are unstable. Fractions connect to ratios. Ratios connect to percentages. Later concepts inherit weaknesses from earlier ones.

So Cuegence would need to represent a curriculum as something closer to:

Curriculum → Grade → Subject → Unit → Concept → Sub-concept → Prerequisites → Learning outcomes

Once that exists, every piece of evidence can potentially be mapped back to concepts. A question in an examination isn’t simply worth four marks — it tests one or more concepts. Homework isn’t merely complete or incomplete; it creates evidence. Teacher feedback creates evidence. An intervention creates evidence. And eventually, delayed recall creates another kind of evidence: whether something that appeared to have been learned remained learned.

That immediately created another interesting problem.

What exactly does it mean for a student to “know” something?

A mastery score of 73% would be convenient, but almost certainly misleading. Evidence has different reliability. A teacher’s observation should perhaps carry different weight than one multiple-choice question. A student can guess correctly. They can make a careless mistake despite understanding the concept. Evidence can contradict itself. Understanding can decay. Confidence should change depending on how much evidence exists and how recent it is.

Suddenly I was reading about knowledge tracing, Bayesian approaches, memory decay, prerequisite graphs, misconception detection, evidence weighting and confidence calibration.

Every answer produced three more questions.

Which, unfortunately, is exactly the sort of thing engineers enjoy.

Then the product started growing around the model

Once you imagine that longitudinal model actually working, dozens of useful applications become obvious.

A teacher preparing tomorrow’s lesson shouldn’t receive a generic AI-generated lesson plan. Cuegence could know what this particular class has already covered, which prerequisite concepts appear unstable, which misconceptions have repeatedly appeared and which previous interventions worked. So it could generate a lesson plan specifically for this class.

A school could generate question papers where every question is already mapped to concepts and learning outcomes. Once teachers entered question-wise marks — or imported them from Excel — the learner model would receive structured evidence automatically.

Homework could become personalized. Instead of thirty children receiving exactly the same worksheet, one learner might receive additional practice on fractions while another revisits percentages and another receives a delayed retention check on something taught three weeks earlier.

Parents could receive small daily or weekly briefs explaining what their child should practise, without exposing some dystopian “your child is currently 63% proficient” score. Leadership could see patterns across classes and subjects.

And every new interaction would feed the model again.

Curriculum creates structure. Teaching creates context. Assessment creates evidence. Evidence updates the learner model. The learner model improves the next teaching decision. The next teaching decision creates new evidence.

It was a proper closed loop.

I loved it.

I spent a surprising amount of time deciding what not to build

The more I thought about the product, the more uncomfortable I became with some obvious EdTech patterns.

I didn’t want children staring at another screen for hours. I didn’t want leaderboards, mastery bars, or “weak student” labels. I didn’t want an AI telling an eleven-year-old that it had calculated they were below average at mathematics. I didn’t want teacher rankings generated by a probabilistic model. And I definitely didn’t want one school’s children being used as a benchmark for another school’s children.

So the product accumulated hard constraints:

Students should never see the system’s assessment of their ability. Parents should receive supportive recommendations rather than performance surveillance. Teachers should remain authoritative. Any inference should be explainable. Teacher corrections should modify the model without deleting the evidence that originally produced the inference. One school’s operational data should never be used to benchmark another school. Direct PII should stay outside the intelligence model wherever possible. AI models should be replaceable infrastructure rather than the product itself. And if deterministic computation could solve something, an LLM shouldn’t be inserted just because it looked impressive in a demo.

Ironically, these constraints made me like the product even more.

It was becoming technically serious.

Then I removed the student application

The first version assumed some direct interaction with students.

That began to feel wrong. If the purpose of the system was to understand learning, why manufacture artificial learning events simply because they were convenient for our software?

Schools already generate enormous amounts of evidence. Tests happen. Homework happens. Assignments happen. Teachers give feedback. Curriculum coverage happens.

So the design changed. Cuegence would primarily learn from normal academic workflows rather than asking students to spend fifteen minutes every day feeding the model. The student-facing product disappeared. The Teaching Copilot became the primary daily surface. Parents could receive personalized practice through channels the school already used. Existing ERPs and LMS platforms could integrate through APIs.

Underneath everything, however, the longitudinal learner model remained. By the third product definition we had explicitly written a product test:

A Cuegence feature should generally either improve the longitudinal learning model with useful evidence, or use the longitudinal learning model to make a better academic decision.

That was probably the clearest definition of the product we ever reached.

And technically, I still think it is a very good idea.

Which was exactly the problem

At this point I had done what engineers naturally do when evaluating a startup idea. I had asked:

Can this be built? What would the architecture look like? What makes it technically differentiated? How do we prevent obvious failure modes? How do we handle privacy? How should evidence be represented? How should the model behave? How can the system become progressively better over time?

These are all important questions.

But they weren’t the most important question.

The most important question was much less intellectually interesting:

Who cares enough about this problem to pay meaningful money to solve it?

I had implicitly assumed that if schools could continuously understand learning instead of looking at marks after the fact, that visibility would obviously be valuable. That assumption felt reasonable.

It was also almost completely untested.

So before writing the product, I started talking to schools.

The engineering rabbit hole had taken me through curriculum graphs, probabilistic learner models, memory decay, privacy boundaries, evidence provenance and personalized teaching.

Six conversations would teach me more about the startup than all of that work combined.

And the answers weren’t particularly subtle.

Continue → Part II: Six Schools and an Uncomfortable Answer