Cuegence Postmortem — Part III: Great Engineering Problems Don’t Make Great Businesses

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

Cuegence never failed.

We didn’t run out of money. We didn’t lose customers. We didn’t discover that the architecture couldn’t scale. There were no production outages, no desperate pivot after eighteen months, no investor update explaining why revenue was “slightly below projections.”

We never built it.

Ten days from first idea to kill decision.

And I increasingly think that was the successful outcome.

The most important thing I learned from Cuegence can be summarized in one sentence:

Great engineering problems don’t necessarily make great business opportunities.

I have always understood this sentence intellectually. Cuegence made me understand it emotionally.

Because I really wanted the engineering problem to be the business.

The technology was the easy part to become excited about

Think about the system we had designed. A structured curriculum graph. A longitudinal concept-level learner model. Evidence provenance. Probabilistic and revisable understanding states. Teacher corrections. Retention and memory decay. Prerequisite relationships. Misconception detection. Intervention tracking. Question-to-concept mapping. AI-assisted assessment generation. Personalized home practice. A teaching copilot that becomes more specific as it accumulates context. Model-agnostic inference. Privacy boundaries. Tenant isolation. Closed-loop feedback where every intervention can produce future evidence.

There are enough research and engineering problems in that list to keep a team entertained for years.

That’s precisely why the idea was dangerous.

Technical depth can create the sensation of value before commercial value has been established. The system feels important because it is difficult to build.

Customers do not care how difficult your system was to build.

They care about what painful thing disappears after they pay you.

I was asking the wrong question

For much of Cuegence’s evolution, I was asking:

How can we make this valuable to schools?

That sounds customer-focused. It isn’t.

The better question was:

What are schools already desperate enough to spend money solving?

Those two questions lead to very different startups. With the first one, you begin with technology and keep searching for a sufficiently persuasive wrapper. With the second one, you begin with an existing budget, pain or strategic priority and determine whether technology can attack it.

Cuegence started from the first direction. We had something that should be useful. Continuous learning intelligence should be better than periodic marks. Personalized practice should be better than uniform homework. A class-aware Teaching Copilot should be better than a generic LLM. Evidence-backed academic decisions should be better than intuition alone.

All true.

None of them automatically imply a purchase order.

The budget line was the lesson

Remember the school from Part II that offered ₹100 per student per month — if Cuegence replaced their complete ERP.

That one sentence contains an entire lesson in B2B software.

Schools already budget for ERPs because ERPs perform operational jobs the institution cannot avoid: admissions, fees, attendance, timetables, records, communication, examinations, compliance. Remove the ERP and somebody’s work breaks tomorrow morning.

Remove Cuegence and what happens? The teacher still teaches. The examination still happens. The principal still sees marks. The school opens normally.

Cuegence might make those systems substantially more intelligent. But “substantially better” and “operationally necessary” live in very different budget categories.

The customer wasn’t misunderstanding our product. They were explaining their priorities.

The two ₹50,000-a-year offers taught a related lesson. A ₹50,000 annual contract can work brilliantly for software that is self-service, standardized and cheap to support. Cuegence was unlikely to be any of those things. Curriculum integration varies. Academic structures vary. Decision-makers vary. Teacher adoption varies. And a system making inferences about children’s learning requires trust — “the AI made a mistake” isn’t an acceptable explanation to an academic head.

This is enterprise-style complexity attached to small-business-style contract values. You can compensate for low ACV with enormous volume, but schools are not Shopify merchants installing an app from a marketplace. Every sale can become a relationship.

That is not necessarily a bad business. It is simply a very different business from the scalable intelligence platform I had imagined.

Distribution was not a footnote — and I actually had distribution

Here’s the part that made the kill decision harder, not easier.

I wasn’t imagining a distribution channel. I had one.

My father spent more than forty years teaching — he understands schools from the inside in a way no market report can provide. Through family, I had a direct line to a publisher with relationships into 200-plus schools. My brother was ready to run sales. For an EdTech founder in India, that is an unusually warm starting position.

Publishers already sell into schools. They already have relationships. They are constantly looking for products that help them win accounts. On paper, this solved the hardest problem in selling to Indian schools.

But a distribution partner — even a family one — cannot manufacture underlying customer urgency.

If the school doesn’t particularly care about longitudinal learning intelligence, changing who introduces the product doesn’t change the answer. It just changes who hears the “no.” The six conversations in Part II were effectively a preview of what my brother would have spent two years hearing.

That’s the lesson I want to underline, because I learned it while holding real distribution assets in my hands: distribution and demand are different problems. A great channel reduces customer-acquisition friction. It cannot turn indifference into urgency.

Then there was the coaching-platform route, and the build-versus-buy question it raised in Part II. Selling a deeply embedded intelligence layer to companies that already own the data, the platform, and the engineering teams demands a real moat. Perhaps proprietary models. Perhaps unique data. Perhaps a network effect. Perhaps an ecosystem standard. Perhaps dramatically faster time-to-value. Perhaps a capability requiring expertise customers cannot realistically maintain internally.

We hadn’t discovered one strong enough.

“The architecture is sophisticated” is not a moat.

The most useful product feature was the kill switch

There is an alternate timeline where we ignore all this.

We spend six months building the curriculum engine. Another six months building the first learner model. We pilot it. Teachers give useful feedback. We improve question mapping. We build dashboards. We discover integration problems. We hire someone for sales. A few schools sign. Every customer asks for slightly different workflows. We proudly announce that we have reached ₹5 lakh ARR.

Meanwhile the engineering system becomes increasingly sophisticated and the company increasingly dependent on founder energy.

Eventually we discover the same thing we could already see before writing the first production migration:

Customers don’t care enough.

That would have been a much more expensive lesson.

Instead, what Cuegence actually produced in its ten days was: three product definitions, a document-ingestion engine with a tokenizer and a classifier, models of the problem, six phone calls, and increasingly uncomfortable questions. One real prototype component, zero production systems, no team, no customers to disappoint.

That’s a pretty cheap startup failure.

I’ll take it.

Some lessons I am keeping

Validate willingness to pay before validating architectural elegance. Not “Would you use this?” Not “Do you think this is interesting?” Not even “Would this help your teachers?” Ask what they would pay. The number forces reality into the conversation.

Find the budget line. If customers like the product but don’t know which budget should pay for it, you may have discovered something useful rather than something commercially urgent.

The replacement question matters. Products that replace an existing expensive activity can demonstrate ROI much more easily than products that merely create additional intelligence. Cuegence augmented teaching and academic decision-making. The school ERP replaced administrative work. The market priced those things accordingly.

Distribution and demand are different problems. I had genuinely good distribution assets. They would have made it cheaper to hear “no” at scale.

“They could build it themselves” matters most when your best customers are technology companies. Selling a deeply embedded intelligence layer to a digital education platform requires a real reason why outsourcing that intelligence creates enduring advantage. We didn’t have one.

Speed of invalidation is a capability. Ten days from idea to kill decision was only possible because AI collaboration compressed the loop between proposing a version of the product and finding its weaknesses. The models never told me to stop — that judgment stayed human — but they made every escape route cheap to explore and therefore cheap to eliminate. The faster you can exhaust the rescue attempts, the sooner the pattern becomes undeniable.

Stopping is also execution. Founders love stories about persistence. Keep going. Pivot. Talk to more customers. Try another market. Sometimes that is exactly right. But persistence becomes dangerous when every negative market signal is interpreted as another product feature you need to build. There is no award for spending three years proving something that six conversations were already trying to tell you.

I still think Cuegence deserves to exist

This is the strange part.

I haven’t changed my mind about the underlying idea. I still think longitudinal learning models are interesting. I still think education software eventually moves beyond storing marks and starts modelling learning over time. I still think memory decay, prerequisite relationships, misconceptions, interventions and evidence provenance can produce dramatically better personalization. I still think a teaching assistant that knows the history of a class is fundamentally more useful than one receiving a prompt five seconds ago.

Someone will build systems like this. Existing LMS companies may build them. Large coaching platforms may build them. Education publishers may absorb them. Foundation-model capabilities may make part of the problem trivial. A company with a completely different distribution advantage may discover the correct business model.

Cuegence being an interesting product does not mean I should build Cuegence as a company today.

That distinction took me embarrassingly long to appreciate — even if “embarrassingly long” turned out to be ten days.

Engineers are trained to see difficult problems and think: “That would be fun to solve.”

Entrepreneurs need another reflex: “Who is already suffering enough to pay me while I solve it?”

Both questions matter. But they are not interchangeable.

A great engineering problem can be intellectually fascinating, technically defensible and genuinely useful — and still be a terrible place to put your next three years.

Sometimes the smartest thing you can build is the conviction not to build it.

What I haven’t resolved

I would like to end there, because it sounds like wisdom.

But here is the honest coda.

The engineer in me still wants to build the learner model. Not the company — the model. The curriculum graph, the evidence pipeline, the decay functions, the provenance layer. I know it may never become a sellable product, and the wanting hasn’t gone anywhere.

I don’t yet know what to do with that. Maybe it becomes a research-writing series. Maybe it becomes open notes and a reference implementation nobody has to buy. Maybe it quietly grows inside a platform I already operate, where the integration tax is zero because the workflows are already mine. Maybe it stays a beautiful idea in a drawer, waiting for a version of the market — or of me — that doesn’t exist yet.

The postmortem is finished.

The problem, apparently, is not.

---

Read the series from the beginning: Part I: I Fell in Love With the Engineering Problem · Part II: Six Schools and an Uncomfortable Answer.