About ten demos, no signed contracts: a demo is not a deal
While repositioning Mindreader I built about ten working demos for different buyers, from an HR screening tool to a face-reading API. The enterprise pitches didn't turn into contracts. Building the demo was the cheap part, and that is exactly why it proved so little.
In 2024 and 2025, while repositioning Mindreader, I built about ten working demos for different buyers. The enterprise pitches didn't turn into contracts.
Each one was a product test: a guess about who the buyer might be, made concrete enough for them to react to. AI has made demos very cheap to build, and the record of these ten shows what a cheap demo is, and isn't, worth.
What I built
Each of these was a working, clickable product, not a slide:
- An HR screening tool. HR sends a candidate a quiz link. The candidate takes it, HR gets a fit score, and candidates who pass come with notes on how to recruit them.
- A client-engagement platform for CIMB's advisers, tailoring how they approach each client.
- Two lead-finding tools, because Mindreader already sat close to sales and communication.
- A face-reading API. I took our face model and sold it directly as an API, as its own product with its own site.
- A consumer face-scanner app built on the same model.
- A proposal generator, built for my own team, to turn consulting enquiries into proposals faster.
We also explored combining Mindreader with a Web3 product, and built a concept site for it. That direction didn't go ahead.
How far the pitches went
Three of them got real attention.
One, with a financial advisory firm, went into detail: I wrote proposals and specifications. Another, with CIMB, went the furthest, with at least two demos and a few rounds of back and forth. A third, with Thriving Talents, a training company we worked with publicly, went reasonably well, but their interest was in training, not in technology by itself.
None of these became a signed contract.
The HR test: same technology, different buyer
The HR tool is the clearest case, because the idea came from Mindreader's own users. Many of them were insurance agents, and insurance agents also build teams. A good number wanted to use the sales tool for hiring: not to sell to clients, but to recruit people into their own team.
So HR was treated as a hypothesis to test, not a new company to start. The hypothesis had two parts:
- Screening. A psychometric quiz could filter for candidates who fit the firm's profile of a successful hire, so recruiters spend less time on people who won't fit.
- Recruiting. Once a candidate passes, knowing how they prefer to be approached could help the firm win them over a competitor. That is the sales product, pointed at a candidate instead of a client.
In 2025 a recruitment and sales-training firm asked whether Mindreader could help them hire. The demo went to its executive board with the proposal, with delivery offered in one to two months, because most of the underlying technology already existed.
The test separated two things that are easy to blur. The technology transferred from sales to HR almost unchanged. The buyer didn't transfer at all: an HR team has different budgets, different risks and a different definition of a good outcome, and each of those had to be learned from the start.
What I take from it
A demo answers "can it be built?" For these buyers, that was never the open question. I could show the thing working in the first meeting.
The open questions were on their side. Who owns this inside the company? Which budget pays for it? What does it replace? A demo can't answer those, and I was answering the question I found easiest.
"We already have the tech" is a seller's reason, not a buyer's. Offering to ship in one to two months was true and useful to me. It wasn't a reason for them to buy.
A training buyer and a software buyer are different customers. When the interest is in training, a better product doesn't move the decision.
How easily the product adapts says nothing about whether a new buyer will pay. Test the buyer before changing the product: who would pay, from which budget, and what they do about the problem today.
I made a related mistake earlier, which I described in Don't build software to fix an explanation problem. Building is what I'm good at, so building is what I reached for.
What I do now
Before I build a demo for anyone, I ask for three things: the name of the person who would own it, the number it should move, and what they'd stop doing if it worked. If a prospect can't answer, a demo won't help either of us yet.
I still build demos. I build them after those answers, not in place of them.