Case study

ProfitLabs

One place to research, compare, and find pricing gaps across Polymarket and Kalshi. I built it solo in under seven weeks. At its peak it tracked around $120M in daily volume for 5,000+ users, with 40%+ day-7 retention. I wound it down in June 2026.

Around $120M in daily volume tracked, 5,000+ monthly users, 6,900+ paired markets, built solo in under seven weeks.

Who used it

Prediction market traders who worked across both exchanges. Polymarket and Kalshi list many of the same events but describe them differently, price them differently, and resolve them under different rules. Anyone trading both needed to compare them manually. ProfitLabs was the screen where they did not have to.

The problem that mattered

The hard part was never the arbitrage math. It was deciding that two contracts are the same contract.

Polymarket and Kalshi describe the same event in different words, with different resolution criteria and different expiry. Pair them wrong and you are not running an arbitrage, you are holding a naked position on a technicality that will resolve against you. The matching worked in stages: normalize both feeds, narrow candidates with heuristics, then put the survivors in front of a model that read the full resolution terms on both sides. Even then the app warned you to check the terms yourself, because a matcher that is right 99% of the time still loses money on the hundredth trade.

What it did

What I chose not to build

No trade execution. Users could find the gap, see the math, and read the terms, but placing the trade happened on the exchange. That kept ProfitLabs out of custody and regulation and let me ship the whole product in seven weeks instead of seven months.

No mobile app. The use case was research before a trade, not reacting to a notification on the train. A dashboard you sat in front of was the right shape. The one concession was the Telegram alert bot, which turned out to matter more than the dashboard itself.

Questions you might have

Why research tooling and not execution? Placing trades means holding customer funds, which means regulation I did not understand well enough to move fast in. The intelligence layer was the part I could own outright, ship in weeks, and iterate on daily. Users who wanted execution already had accounts on both exchanges. They needed the comparison, not another place to click Buy.

How did you validate matching accuracy? Every matched pair carried a confidence score and a link to both sets of resolution terms. The app warned users to check the terms themselves. I tracked how often users flagged a bad match and fed those back into the model. False positive rate landed under 1%, but in arbitrage even 1% is a real cost, which is why the warning stayed.

What would you do differently? I would have built the Telegram alert system on day one. For the first two weeks I had no way to know what was happening without opening the dashboard. Once alerts existed, usage patterns changed: people checked the app less often but acted on it more. The push model was the real product.

Screens

Three minutes through the product, narrated, recorded May 2026.
The arbitrage scanner, listing opportunities across matched pairs with Polymarket and Kalshi prices, profit and return side by side.
The arbitrage scanner. Every row is the same contract priced on both exchanges, with profit after fees and return.
The dashboard, showing whale activity with trade sizes, a live whale feed, a watchlist, and markets expiring soon.
Whale activity and the live feed. Trades landed here within a second of hitting either exchange.
A single market view comparing the same contract priced on Polymarket and Kalshi, with order book and price history.
One contract, both venues, one screen. The gap between those two numbers is the whole product.

Next.js, React, Python, FastAPI, WebSockets, Supabase, Claude API, Docker, GCP.

Wound down, June 2026.

Back