Notes From Shipping an AI Product Nobody Asked For

Nobody asked us to build Anna. There was no inbound, no feature request, no “customers are begging for verified market analysis.” We built it because we kept watching AI answers about stocks that sounded certain and turned out to be wrong, and we were convinced that problem was going to get worse, not better, as more investors leaned on AI. Here are the operator notes, the parts that don’t make the launch tweet. In one line: the bet was that verifiability would beat fluency, and so far, it has.

The bet

The market didn’t believe trust was the bottleneck. Everyone else building AI-for-investing was racing to make the model sound more confident, more fluent, more like an analyst. We bet the opposite: that a confident wrong answer is worse than no answer, and that the winning product would be the one that made every claim traceable back to the actual ASX filing it came from, even if that made it slower and less flashy than the competition. That’s a conviction you can’t validate in advance. We only found out we were right because we shipped it and watched what users actually trusted.

What shipping actually looked like

Not the demo. The demo is “ask Anna a question, get a clean answer with sources.” The 80% nobody sees was going directly to the source instead of scraping the web: negotiating a direct real-time ASX data licence, building the pipeline that ingests every announcement and filing as it’s published, and wiring every single number Anna states back to the filing it came from so a user can click through and check it themselves. None of that is impressive in a screenshot. All of it is the difference between a tool that sounds right and one you can actually rely on before you trade. For an AI product, that last stretch, the part where it’s trustworthy and not just articulate, was most of the work.

What surprised us

• We assumed the flashiest capability, generating a polished-sounding answer, was the value. Users were politely enthusiastic about that and quietly unmoved. The thing that actually earned trust was the boring, invisible part: the source link under each claim.
• We trusted our own evals because they said the feature was ready. They were built from cases we’d already thought of, so of course they passed. Real users found the other ninety percent, the questions we hadn’t imagined, in the first week.
• We thought hiding uncertainty made the product look more finished, so early versions gave confident-sounding answers with no “here’s what I’m not sure about.” The first time Anna was wrong with full confidence, users stopped trusting it everywhere, not just on that answer. The small detail, showing uncertainty honestly, turned out to be the whole product.

What worked

The two things that landed: real-time data straight from a licensed ASX feed instead of scraped web content, and answers that link back to their source instead of asserting them. Both are unglamorous, and both are why people keep using Anna instead of asking a general-purpose chatbot the same question. The honest read: the bet paid off on the trust question, people do choose verifiable over merely fluent, but we’re still earning the coverage and speed that would make Anna the first place a serious investor looks, not just a second opinion.

The takeaway

Building something nobody asked for is only stupid if you’re wrong about what the market actually needs versus what it says it wants. Nobody asks for “please make the sources checkable”, they ask for a faster answer, and only tell you which one they trust after they’ve been burned by the fast one. The job of an operator is to ship the smallest honest version of the uncomfortable bet, put it in front of real users, and let reality, not the pitch, grade your conviction.

What would we do differently next time? Build the source-verification pipeline first, before the answer-generation layer, instead of the reverse. We built the part that sounds good before the part that’s true, which meant the most important engineering work started later than it should have. If trust is the actual product, treat trust as the critical path from day one, not the polish you add once the demo works.