Stop Building AI for AI's Sake — How VC Mindset Transforms Product Evaluation
$ grep -n "^##" 2025-10-stop-building-ai-for-ais-sake-vc-mindset-transforms-evaluation.md>
- 1:The demo that works and solves nothing
- 11:The bank doesn't care about your architecture
- 19:What the smart money actually evaluates
- 33:Two companies that won by being boring
- 39:When the technology leads, here's how it dies
- 53:The questions I ask before I believe a demo
- 76:Why finance got here first
- 80:Adopting the lens on purpose
The demo that works and solves nothing
I sit on both sides of the table. Most weeks I'm building — orchestrating four or five Claude Code agents across my own projects, watching what survives contact with production. In a venture-builder context, I'm also one of the people a founder walks through their AI product hoping for a cheque. So I've developed a reflex. Thirty seconds into a demo, while the model is doing something genuinely clever on screen, I've stopped watching the model. I'm waiting for the founder to tell me which human's afternoon just got shorter, and by how much. Most never get there. The demo works. It solves nothing anyone was paying to have solved.
That gap has a price tag. Repairing a failed AI implementation runs about €710,000 ($750,000) — roughly double the original budget, before the year spent building the wrong thing. And the wrong thing is the norm. Read the post-mortems and the cause is almost never the model; it's that nobody upstream asked whether it answered a question the business actually had.
The reference case is IBM Watson for Oncology. IBM spent over $62 million on a system that issued unsafe treatment recommendations and got shut down, then folded the whole Watson Health division after pouring in billions. A marvel pointed at no clinician's real problem. I've watched the small-startup version more times than I can count: a team in love with what they built, unable to name the customer whose day it changes.
So here is the lens I actually use — not a technology lens, but the question every good investor asks and most engineers forget to: who needed this, and how will we know it worked?
The bank doesn't care about your architecture
Amir Elkabir, who wrote "Lead with AI," put it in a single sentence that I've quoted in pitch meetings since:
"Banks don't care about model architecture—they care about lowering audit workload"
The proof is in what banks measure. When JPMorgan Chase put AI on commercial loan review, the headline number wasn't a benchmark — it was 360,000 hours saved annually, a procurement officer's language, not a researcher's. The whole culture orients toward compliance, cost reduction, and measurable return. AI compliance monitoring cuts review time up to 90%, taking 1,000 recorded conversations from 500 hours a month to 50. BNY Mellon's automation hit 100% accuracy in account closures and $300,000 in annual savings. Every figure is denominated in money or time, none in cleverness. The best AI buyers talk about it the way an investor talks about a company — and it's worth asking why the builders so often don't.
What the smart money actually evaluates
Venture capitalists got their inoculation against technology hype the hard way, surviving the dot-com bubble. The frameworks they built afterward are multi-dimensional and ROI-first: data strategy, market fit, team, a credible path to return — algorithmic sophistication doesn't make the front page anymore. The question is no longer "is the AI impressive?" It's "does the AI move a number someone is willing to pay for?"
In practice that resolves to three things I look for, in order:
- A data moat, not an algorithm. VCs prize unique, high-quality, scalable datasets — the model is a commodity in eighteen months and the data isn't.
- Unit economics that survive a spreadsheet. Revenue model, acquisition cost, contribution margin — not the architecture diagram.
- Evidence a stranger can check. Independent benchmarks, case studies, signed contracts — claims I can verify without the founder's word.
BMW i Ventures says the quiet part at full volume: "I don't care about your next-gen neural net. All that matters is if the darned thing works." Jenny Fielding at Everywhere Ventures sharpens it: "AI is an enabling technology—it's not the business itself."
I'll be honest about my own bias, because it cuts both ways. I love the engineering. Running a swarm of agents across a codebase is the most fun I've had building software in twenty years. Which is exactly why I don't trust myself in a demo — the investor reflex is the discipline that stops me funding the version of a product I'd enjoy building over the version a customer would pay for.
Two companies that won by being boring
UiPath didn't win VC backing with a flashy model. It won by handing enterprises efficiency gains and cost reductions they could put on a spreadsheet inside a quarter. Databricks did the same — not a better algorithm, a better outcome from the data a company already had. On the factory floor it shows up as 280% ROI over 18 months, predictive maintenance cutting expenses 30–40% against reactive models.
They all started from a business problem and reached for technology only when the problem demanded it. The cool part was incidental.
When the technology leads, here's how it dies
"AI project failed" is too vague to learn from. Every spectacular collapse below has the same shape: a powerful capability deployed in front of a business requirement nobody mapped first.
IBM Watson for Oncology, trained on hypothetical patient data and built as a showcase, gave unsafe treatment recommendations. The sophistication was real; the clinical requirement was an afterthought.
Amazon's AI recruiting tool downgraded resumes containing the word "women," having learned from a decade of biased hiring. Fairness and legal exposure were business requirements never in the spec.
McDonald's drive-thru AI got shut down after years and millions because it misheard orders. Excellent speech recognition met the real conditions of a drive-thru and lost.
Air Canada's chatbot invented a bereavement-fare refund policy, a customer relied on it, and a tribunal held the airline liable. A capable model with no connection to the company's real rules generated a legal liability.
In every case the AI did the thing; the failure was upstream of the engineering. The hard question is no longer "can the AI do it?" but "can a human verify it's the right thing before the business acts?" The capability outran the verification, every time.
The questions I ask before I believe a demo
Peak Capital uses 31 questions to separate real AI ventures from theatre. You don't need all 31, just the handful a founder in love with their model can't answer without flinching. They work just as well pointed inward, at your own roadmap, as across a pitch table.
Start where the AI isn't.
- Describe the customer's problem without using the word "AI." If you can't, you don't have a problem, you have a technology looking for one.
- Is that problem currently costing measurable time or money? Name the figure.
- Would a boring, non-AI solution do nearly as well? (If yes, build that.)
Make the win measurable.
- Which specific KPI does this move — revenue, cost, hours, error rate — counted in dollars and time, not vibes?
- Which business stakeholder picked that metric, and will they sign their name to it?
Demand evidence a stranger can check.
- Pilot results, case studies, an independent benchmark — a demonstrable improvement over today's process that I don't have to take on faith.
Pressure-test the moat and the failure modes.
- What proprietary data or integration makes this hard to copy next year?
- What breaks it, who gets hurt when it breaks, and how is that contained?
- What does it cost to own — including the maintenance nobody budgets for?
A founder who reaches for model performance every time you ask a business question is telling you, gently, that there's no business underneath the model.
Why finance got here first
Banks didn't develop this discipline because bankers are wiser. Regulation gave them no choice, and that accident of constraint turned them into the best AI buyers in the economy. The EU AI Act's requirements for "high-risk" applications force a bank to evaluate a tool on what it does to compliance, not how clever it is; before adoption they demand compliance documentation and third-party risk assessments. The results land in the success column — Wells Fargo's assistant handled over 20 million interactions — and as S&P Global notes, the advantage goes to banks "with the capacity and flexibility to make best use of them". Best use is a business judgment, not a technical one. The rest of us choose this discipline voluntarily, which is harder, because nobody's forcing our hand.
Adopting the lens on purpose
The working habit: refuse to let the technology choose the problem. Elkabir says it cleaner than I can — "unless AI is implemented to solve tangible business problems, it is all just noise" — and Darren Ott at Dolby reaches the same place from the engineering side: "look at the problem you want to solve, and then bring the technology in to fix it rather than saying, 'let's have AI.'"
The practice is small, fast, and humbling. VCs expect founders to build an MVP and test the assumption quickly rather than design a cathedral on day one — the same instinct that has me throwing four agents at a narrow slice of a problem before I trust it at scale. McDonald's China is the textbook case: aiming AI at one workflow, monthly employee transactions went from 2,000 to 30,000.
Then make the metric non-negotiable before anyone writes code. Five Sigma's claims system shipped an 80% drop in errors; John Deere's vision system cut herbicide use by more than two-thirds. Those numbers existed as targets before they existed as results — the tell of a project built business-first: the success criteria predate the technology. And someone has to carry it: the teams that move AI from pilot to production almost always have an internal champion fluent in business value, weighing each idea through compliance, risk, operations, and impact at once. Finance does this by default; everyone else builds the muscle on purpose.
I came into AI as a builder — twenty years of it, from server racks in London Docklands to whatever I'm shipping from Singapore this week — and a builder's instinct is to be moved by what's possible. The investor reflex is the corrective: be moved by what's needed. Both have to live in the same head, because the most dangerous AI project isn't the one that fails. It's the one that works beautifully, demos brilliantly, costs three quarters of a million to unwind, and answered a question nobody was asking.
The Cutler.sg Newsletter
Weekly notes on AI, engineering leadership, and building in Singapore. No fluff.
The Quiet Failure Inside the Agent
AI agents don't fail loudly — they degrade silently, returning 200 OK while the damage compounds. Inside the $47K loops, NOHARM omissions, and the engineering discipline rebuilding observable failure.
The Productivity J-Curve: Why Your AI Pilot Looks Worst at Week 6
METR ran the experiment. AI made experienced developers 19% slower — and they reported feeling 20% faster. The week-6 dip is the bottom of a documented J-curve. Most pilots get cut here. The right ones don't.
Three Ingredients, Three Labs, One Squeeze: Reading the 2026 AI Compute Crisis
Anthropic just leased Elon Musk's supercomputer four months after he banned them. Here's the three-ingredient framework that explains why — and what it means if you build on Claude.