Cuegence Postmortem — Part II: Six Schools and an Uncomfortable Answer

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

The original proposition behind Cuegence was roughly this:

Schools need better visibility into learning.

Cuegence would continuously transform academic evidence into longitudinal learning intelligence for students, classes and schools. By the third product definition, the idea had become substantially better than where it started. That should have been encouraging.

Instead, it became increasingly worrying — because I had started questioning the commercial assumption underneath it.

Would a principal actually wake up thinking, I wish I had a probabilistic concept-level model of every learner?

Probably not.

Would a school owner choose one school over another because the second had better learning-intelligence dashboards?

Probably not.

Would teachers look at the system and say, “Finally, somebody can tell me how my class is doing”?

That one became especially uncomfortable.

A reasonably competent teacher who spends every day with a class of forty or fifty students already knows a surprising amount about them. They know who is struggling. They know which chapter went badly. They know who didn’t understand fractions. They know when half the class has mentally disappeared.

Cuegence might know these things more systematically. It might retain them longitudinally. It might find relationships across assessments that a human misses. But “better information” doesn’t automatically mean “valuable enough information that someone buys software for it.”

That distinction started changing the product.

Pivot one: schools don’t buy insight, perhaps they buy teacher augmentation

If the dashboard wasn’t enough, perhaps the intelligence needed to directly improve the teacher’s work.

So Cuegence became an AI Teaching Copilot. Now the pitch wasn’t “here is better visibility.” It was “give every teacher curriculum-aware, evidence-informed support.” Lesson preparation. Question-paper generation. Formative questions. Homework. Rubrics. Assessment design. Intervention suggestions.

The longitudinal model would make these outputs better than what a generic LLM could generate, because Cuegence would know the accumulated learning history of the actual class.

This was a much stronger product story. It also solved another real problem: excellent teachers are difficult to scale. A school may have one extraordinary mathematics teacher and three average ones. Technology cannot manufacture charisma, judgment or human connection, but perhaps it can make good academic preparation more repeatable.

That sounded commercially better. For a while.

Then another problem appeared. There are already an absurd number of AI teaching copilots. A teacher can open ChatGPT, Claude, Gemini or half a dozen education-specific products and ask for a lesson plan today. If Cuegence became “AI lesson planning for schools”, we would be building a commodity feature.

So we moved the longitudinal learner model back to the centre. The Teaching Copilot wasn’t the moat. The accumulated model of learning was supposed to be the moat.

Pivot two: remove the student app and integrate with everything

The next objection was adoption.

Schools already have enough software. Teachers already have enough administrative work. Parents already have school apps and WhatsApp groups. Students already have enough screens.

So instead of forcing everyone into another Cuegence application, we removed the student-facing product entirely. Cuegence would become more infrastructure-like. Use the school’s existing assessments. Import marks from Excel or APIs. Ingest homework and teacher feedback. Integrate with existing LMS and ERP systems. Send parent recommendations through WhatsApp, email, Telegram or the school’s own app.

The system would disappear behind workflows that already existed.

Again, the product became better. Again, I liked it more.

And again, none of this answered the question of whether anybody wanted to pay for it.

So I asked six schools

Not a hypothetical TAM analysis. Not a Gartner report. Not “India has X lakh schools, and if we capture just 1%…”

Through mutual connections, I reached decision-makers at six schools — the people who actually sign purchase orders — and got roughly ten minutes on the phone with each of them. Enough time to explain the product plainly and ask one very simple question:

If this product existed, how much would you pay for it?

Let me be honest about what this was and wasn’t. Six ten-minute phone calls is not customer discovery by any respectable standard. There was no demo, no pilot, no extended needs analysis. If the answers had been enthusiastic, I would have trusted them far less than I trusted what actually came back.

Because what came back was not enthusiasm.

Three schools effectively said:

Nothing. We don’t need it.

Two said:

Around ₹50,000 per year.

One said:

₹100 per student per month — if it can replace my complete school ERP.

That last qualification may have been the most useful answer of all. Cuegence’s product definition had explicitly said: Cuegence is not a school ERP. The customer was effectively saying: Fine. Then I’m not paying ₹100 per student per month for it.

Ten minutes per school was enough, because the question wasn’t subtle. When a product genuinely attacks something a buyer is desperate about, ten minutes is plenty of time for them to start negotiating. Nobody negotiated.

The numbers were more important than the compliments

₹50,000 a year sounds like revenue.

But revenue without considering the cost of acquiring and serving that customer is just a comforting number.

Imagine selling a technically sophisticated B2B education platform to schools for ₹50,000 per year. Sales conversations. Demos. Follow-ups. Academic stakeholder meetings. IT integration. ERP compatibility. Excel formats that somehow differ in every institution. Teacher onboarding. Curriculum configuration. Support. Training. Data-security discussions. Renewal conversations. And because education data involves children, you should be taking privacy and security far more seriously than the average ₹50,000 SaaS product.

At ₹4,167 per month in revenue, you don’t need a sophisticated spreadsheet to discover the problem.

Then there were the three schools whose willingness to pay was exactly zero. They weren’t saying “this is a bad implementation” — there wasn’t an implementation. They were saying:

The problem itself isn’t important enough to us.

That’s much harder to fix.

I kept trying to rescue the idea

This is one of the dangerous things about technically interesting products. Every market objection can be interpreted as a product-design problem.

Schools don’t want dashboards? Make a copilot. Teachers won’t use another app? Remove the app. Parents won’t log into anything? Use WhatsApp. Schools worry about PII? Keep direct identity outside the intelligence layer. Generic AI can generate lessons? Build longitudinal learning context. School sales are difficult? Sell through publishers. K–12 budgets are bad? Target coaching institutes and digital education platforms.

Every answer makes sense.

And if you’re not careful, you can spend years fixing the product without ever fixing the business.

Maybe Cuegence shouldn’t be a product at all

There was another escape route that looked even cleaner.

Don’t sell another application. Become an intelligence layer for applications that already exist.

Moodle has an enormous installed base. WordPress-based products such as Tutor LMS serve smaller education businesses. There are dozens of other LMS platforms sitting between those two extremes. Why not build Cuegence plugins for them? Install the plugin, Cuegence starts receiving assessment activity, course progress, assignments and other learning signals, and the institution gets longitudinal learning intelligence without replacing its LMS.

On a whiteboard, this looked brilliant. Build once. Publish plugins. Let existing LMS ecosystems bring customers to us.

Except the more I thought about it, the less “plugin” meant what I wanted it to mean.

Installing the software could perhaps be one click.

Making the intelligence useful could not.

Two institutions can both run Moodle and have completely different academic workflows. One might conduct every assessment inside Moodle; another might upload PDFs and collect answers offline. One might have carefully structured quizzes; another might only publish final marks. Question-level marks may exist in one system and not another. Learning outcomes may be mapped properly in one institution and completely absent in another. Assignments might be graded numerically, through rubrics, through comments, or outside the LMS entirely.

And Cuegence needed more than events such as: Student X completed Quiz Y and scored 72%.

The entire premise depended on understanding what evidence actually meant. Which concepts did the questions test? Was this formative or summative? Was the learner allowed multiple attempts? How reliable was the assessment? What was taught before it? Which teacher feedback should influence the model?

A Moodle plugin could connect us to Moodle. It couldn’t automatically connect us to the institution’s academic reality.

We had found a potentially easier way to install Cuegence.

We had not found an easy way to integrate Cuegence.

For an intelligence product, those are very different things.

The integration tax was hiding inside the product

This became another uncomfortable realization.

No matter which market we selected, Cuegence needed context. Without context, it becomes generic analytics. And context lives inside other systems and human workflows.

That means integrations weren’t auxiliary work sitting outside the clever learner model. Integrations were part of the product. Perhaps a huge part. ERP data. LMS data. Assessment structures. Curriculum models. Question mappings. Teacher feedback. Assignment workflows. Parent communication. Institution-specific academic rules.

Every new deployment potentially required discovering how that institution produced evidence before Cuegence could begin interpreting it.

The irony was becoming hard to ignore.

We wanted to build a sophisticated longitudinal learning model.

We might spend most of the company’s time writing adapters.

Maybe K–12 itself was the problem

So I considered higher education.

Universities have larger student populations, LMS platforms, substantial digital data, IT teams, and sometimes bigger budgets. I also work close enough to higher education systems to understand how much institutional data exists. At first glance, it sounded like a much more promising environment for Cuegence.

Then I tried mapping the actual learning loop. And the problem almost reversed.

School education is relatively structured. A teacher sees a class repeatedly. A curriculum progresses over months. Homework, class tests, unit tests and examinations create recurring evidence. There are many opportunities for a model to observe learning changing over time.

Higher education moves differently. A course may run for one semester. A faculty member may teach hundreds of students. Different subjects have completely different assessment structures. There may be a mid-semester examination, a few assignments, a final examination — and not much useful structured feedback in between. Students move from course to course. Faculty change. Some learning happens inside the LMS; a lot happens outside it. Detailed teacher feedback at the individual learner level is difficult to collect consistently at scale.

The longitudinal model still sounded fascinating. But what exactly would feed it?

If the available signals are sparse, delayed and inconsistent, the problem changes. Instead of asking how do we turn learning signals into useful longitudinal intelligence, we would spend our time asking:

How little signal can we get away with and still pretend the analysis means something?

We would no longer be building Cuegence because institutions had rich evidence they desperately needed help understanding. We would be inventing mechanisms to create enough evidence so that Cuegence had something to understand.

That felt backwards.

Then coaching looked like the perfect market

The coaching-market idea was particularly tempting.

Coaching companies already operate digitally. They already collect learning data. They already have online classes and apps. They care about outcomes. They need to identify which students are progressing. They have more money than many schools.

Perfect. Cuegence could become the “intelligence layer for digital education.” Plug into existing platforms. Build the longitudinal model underneath existing coaching products. No separate student app. Richer signals. Far larger learner populations.

It looked like another elegant escape route.

Then came an even simpler question.

Suppose I walk into a big company in the coaching domain and tell their product head: “We have an intelligence layer that can build longitudinal models of learning from your existing platform data.”

What stops them from saying:

“Interesting. We’ll build it ourselves.”

They already own the data. They already own the student relationship. They already own the LMS. They already employ product and engineering teams. If this capability becomes strategically important, building it internally may make more sense than introducing a deeply integrated third-party dependency into their academic core.

The market had changed.

The fundamental problem had not.

This was no longer a positioning problem

By now, we had tried several possible commercial wrappers around the same engineering core: learning intelligence for school leadership, teacher augmentation, personalized home practice, academic infrastructure, LMS plugins, higher education, digital-education intelligence.

Every version made some sense. None produced strong evidence of a market pulling the product out of our hands.

Worse, each market introduced a new prerequisite before we could even reach the interesting part. Schools required integrations and behavioral adoption. LMS platforms solved software distribution but not academic integration. Higher education gave us scale but weaker continuous signals. Large coaching companies had better signals but stronger incentives and capabilities to build the intelligence themselves.

We weren’t converging on a market.

We were moving the problem around.

That is a very different situation from having a badly positioned product. Positioning problems can be fixed. Feature problems can be fixed. UI problems can be fixed. Architecture problems can definitely be fixed.

Weak customer urgency is much harder.

The six-school survey didn’t prove that nobody in the world would buy Cuegence. That would be an absurd conclusion from six ten-minute phone calls. But startup decisions don’t require mathematical proof. They require enough evidence to decide where to spend finite years of your life.

And the evidence was saying something very clearly:

Cuegence might solve a sophisticated learning problem.

It did not appear to solve an expensive enough customer problem.

Those are not the same thing.

That distinction eventually killed the startup before the startup existed.

Which, in retrospect, may have been the best possible outcome.

Continue → Part III: Great Engineering Problems Don’t Make Great Businesses