← All experience

I built a fund product for people who couldn’t read a dashboard

CausalCo-founder, product Feb — Jun 2026Shut down

Prediction market intelligence, built by three of us. I owned design, frontend, data visualisation and the product surface, and I built Safe Buckets end to end.

The short version

Three of us built an intelligence layer for prediction markets. Every market got decomposed into a graph of the real-world events driving it, fed by a news pipeline that attributed price moves to specific published stories.

The first piece of user feedback we ever got said the product was full of data and short on direction. I spent the next four months learning that this was not a UI problem. It was the whole thesis.

We shut down in June. Polymarket became inaccessible in India and the team came apart at the same time. Along the way we changed position three times, got rejected by YC, and shipped one thing I would build again.

A walkthrough of the shipped product: the watchlist, the event feed, the causal graph and custom node graphs, and the community layer. Open on Loom if the player doesn’t load.
15 → 30Users, first count to last. 20 daily at the end.
6 strategiesFour ended profitable, two didn’t.
1–2% / monthVault return once the strategies matured.
₹0Pre-revenue throughout. No entity was ever formed.
The feed. Each item leads with the price move and the driver we attributed it to, then the market underneath. The rail on the right was the first place a user could act instead of read.

What we were building

Prediction markets had gone mainstream after the 2024 US election, but the tooling around them hadn’t. Every product in the space was built for people who already traded: whale trackers, volume spikes, order book depth. Nothing was built for the much larger group who follow the news, have opinions, and can’t work out where to start.

Our answer was an intelligence layer. Each market got decomposed into a graph of the real-world events that actually drive it, fed by a real-time news pipeline that attributed price movements to specific published stories.

My co-founder Aditya built that engine: news ingestion, clustering, causal graph generation, the mapping from news to market. I built what you see — the graph visualisation, the market pages, the feed, the onboarding, and eventually Safe Buckets.

The rules behind the graph

Two rules did most of the work here, and both were about refusing to draw things.

  • Edges carry causal direction, not correlation. Two nodes that move together don’t get a line. Drawing correlation would have been easier and would have filled the canvas, and it would have turned the graph into a horoscope.
  • The timeline only admits real events. Items the pipeline classified as events scoring above an importance threshold get in. Analysis and rumour get dropped.
The Advanced view: the outcome at the top, the factors that drive it below, and their sub-factors below that. Every node carries its own probability, and the edges are coloured by whether the factor supports or opposes the outcome.

Every surviving event is anchored to the earliest article that published it, then matched against the market’s price movement in a two-hour window around that timestamp.

The timeline tab. A card has to earn its place: a timestamp, the price impact we matched to it, and the outlets that carried it. The State Department item matched on a chunk-level anchor rather than a headline keyword, which is the part of the pipeline that took longest to get right.

The feedback I should have acted on faster

Our first real user response, in February:

The UI is nice but there’s too much info to process. You need to focus on communicating to the user what you intend him to do, plus empowering the curious with data. I am empowered with data but don’t have clues on what to do with it.

First user response, February 2026

I treated this as an interface problem. I wrote a brief that month about designing for someone with no Polymarket knowledge, applying Don’t Make Me Think, not overwhelming anyone. I revamped the UI and rebuilt onboarding.

What I shipped: a Simple view that opens with one sentence naming the factors driving the price, with Advanced kept one click away for anyone who wanted the whole graph.

All of that was correct and none of it was sufficient, because the problem wasn’t that the data was badly presented. It was that data was the product. A sentence at the top of the graph tells you why the number moved. It still doesn’t tell you what to do with $50.

By the time we wrote our YC application, I could state it plainly: nobody wants more data or more parameters, they want to know what happened and what to do. That’s the same sentence the user had given me four months earlier.

This is the second time I learned this, and I had the evidence in hand.

At SummonLM we built a measurement product where both active pilot customers used only the prescriptive half, the part that told them what to fix, and neither touched the analytics the entire pitch was built around. I had that evidence and built another measurement product anyway.

Safe Buckets

Safe Buckets was the first thing we built that answered the question instead of illustrating it.

A user who doesn’t understand prediction markets cannot pick a market. They can pick a bucket. So a bucket deploys USDC across a pre-defined strategy: markets in one category, already priced above a probability floor, close to resolution, spread across multiple sub-buckets so no single position can sink the round. You deposit. The vault trades. You watch NAV.

Six strategies across politics, crypto, geopolitics and sports. Four ended profitable, two didn’t, and the two that didn’t stayed on the page with their losses showing. The Safe Buckets and timeline screens here are rendered from the product’s own frontend source against a representative data snapshot.

I built this end to end, strategy parameters and product. The interesting part is not the interface. It’s the constraints.

Every parameter a bucket trades on, laid out before you deposit a dollar, with the vault’s own numbers above it.
RulePolitics CoreWhy it exists
Volume floor is total volume, not 24h≥ $250,00024h volume makes a thin market look liquid
Max entry priced against CLOB best ask, not midpoint94.0¢Midpoint pricing is a fiction you can’t execute at
Stop loss is an absolute price, exit at next sellable bid78¢If the best bid vanishes, “stop at X” means nothing
Order notional capped against book depth12% of depthA position you can’t exit isn’t a position
Cap per market, spread across sub-buckets8% NAV × 4Resolution risk is binary and unhedgeable

These live in the type definitions rather than in a document. We built the whole platform with Claude Code and Codex, and a constraint written in prose gets paraphrased away across a few hundred generated lines. A constraint that’s part of the type signature doesn’t. That’s a working practice I’d carry into any team building this way now.

NAV across seven rounds, then the live round: how much of it has resolved, and every slot in all four buckets colour-coded by whether it won, lost, is still open or has yet to be entered.

Deposits enter at the next round and withdrawals settle at NAV once open positions resolve. That was the piece of vault mechanics every user asked about, so I put it under the button in plain language instead of in a docs page.

Order history with one loser and one still pending entry, then every round including the one that lost money. A vault that only shows you the winning rows is a marketing page.

Six strategies, four profitable, 1 to 2% per month once they settled. Early rounds ran hotter and more volatile, up to 7% in a week, which is the number that went into the YC application. The settled number is the honest one and it’s the one I lead with.

I never turned on the revenue infrastructure. Taking a fee on vault returns was the obvious path and I kept deferring it in favour of usage.

Three positions in five months

We didn’t pivot once, we pivoted twice, and I think both were right.

One: decentralised news oracle

The thesis was that prediction markets would function as a truth machine. It didn’t hold. Too many markets have liquidity too thin to be a reliable signal, and the market page above is one of them: $1.6M of lifetime volume, top quartile by volume, and zero liquidity on the day it resolves. We killed the framing and kept the pipeline, which is what every later version ran on.

Two: retail intelligence layer

Event graphs, help newcomers understand why odds move, freemium at $15 to 25 a month. This is what we pitched in April and what most of the product was built for.

Three: index and ratings infrastructure

This one came from an analogy rather than from user research, and it’s the best strategic thinking I did all year.

Individual prediction markets are too thin and binary to build derivatives on. A market moving from 45% to 50% isn’t tradeable, and at $48K of liquidity one spike blows up any position. But equities solved exactly this, and they solved it in a specific order: single-stock derivatives didn’t get adoption first, index derivatives did. The S&P 500 smoothed single-stock noise into something deep and liquid enough to trade, and single-stock derivatives followed.

So you build the index first. A trader who thinks tension is rising doesn’t need to pick a market. They buy the index.

And the ratings layer has a structural moat that isn’t technical: neither Polymarket nor Kalshi can credibly rate the other’s markets, and legacy providers will wait for regulatory clarity. The first independent ratings provider becomes the standard, the way Moody’s did in bonds.

We never built it. Position three was a thesis and a pitch, not a product. We applied to YC Summer 2026 on it and were rejected.

What I did before the YC application

I wrote down the ten hardest questions an investor could ask us, in a document, before any meeting.

  • You didn’t use prediction markets yourselves.
  • No revenue, under 100 users, and you’re calling this traction.
  • Your TAM conflates trading volume with revenue.
  • What stops Polymarket building this themselves.
  • Three months in with no prior startup experience.
  • Why isn’t this a lifestyle business.

Most of the reasons we were rejected were in that document before we applied. I’d rather have written it than not, and I’d do it again on the next thing.

How it ended

Two things happened at once. Polymarket became inaccessible in India, and there was conflict within the founding team.

The regulatory change removed our market. The three of us didn’t agree on what to do next.

I concluded I’d made a mistake at the start: I never checked whether this was the right team for this specific idea.

What I’d do differently

Test whether the product changes anything, before building more of it. At both companies I built measurement tools and never instrumented whether acting on the measurement moved the outcome. A product that can’t measure its own effect can’t prove its data is worth paying for.

Take the revenue signal when it appears. I had a willing payer at SummonLM and usage concentrated in one feature here, and in both cases I kept building instead of charging.

Pick the position before building the product. The April product was built for position two and the YC application pitched position three. The code and the pitch had drifted apart, and the gap was visible to anyone who looked at both.

Credits

Aditya Gupta built the backend, the causal graph engine, the news pipeline and the LLM systems. Aayush Agarwal led financial modelling and risk. I owned design, frontend, data visualisation, the product surface, and Safe Buckets.

The YC application split our roles by primary domain and lists yield strategies under Aayush. In practice I built Safe Buckets end to end, parameters included.