Bitcompare
Product Lead, 2019–present
- 42,131
- rates normalised across 57 providers and 620 assets
- 31,168
- rate updates in 24 hours, ~3 minute median refresh
Context
Bitcompare is a crypto yield-intelligence platform. It maintains one normalised data layer for lending, staking, borrowing and stablecoin yield across CeFi and DeFi, and exposes it through a structured API, MCP tools for AI agents, publisher integrations, comparison surfaces and a provider marketplace.
I have been Product Lead since 2019. The work described here is the decision to treat the data as the product, and everything that followed from it.
Problem
Selling attention has a ceiling. Rank for a commercial query, send a click, take a fee: the business is then worth exactly as much as the traffic it rents, in a category where the providers themselves run content budgets an order of magnitude larger. One channel moves and the revenue moves with it.
Meanwhile the actual asset sat underneath, unpriced. Making yield rates comparable across dozens of providers is continuous, unglamorous work, and we were giving the result away for free.
The second pressure was the buyer changing. The thing consuming yield data was increasingly an AI assistant answering a question about the best rate, not a human reading a table. Anything optimised to win the click was on the wrong side of that shift.
My role
Product strategy and execution for the repositioning. What category the company is in, what the products are, who pays for each, how they are packaged and priced, and what has to be built in what order. The engineering lead owns the data pipeline and infrastructure, so the sequencing was a joint call.
Insight
Every provider publishes rates and none of them are comparable. Different compounding, different lock-ups, different tiers, different definitions of APY, different treatment of promotional rates, different regional availability. Aggregation is trivial. Normalisation is the hard part, and it is exactly the work an integrating team does not want to do in-house.
The second insight came from looking at what we were failing to capture. We logged clicks but not impressions, which meant we could describe activity and not demand. A provider getting 500 clicks from 5,000 impressions is in a completely different position from one getting 500 from 50,000, and we could not tell those apart. The denominator was the product we were sitting on and not collecting.
Product decisions
Normalisation is the product, not aggregation.
Anyone can scrape rates. What is defensible is the schema and the rules underneath it: asset, provider, yield type, base versus max rate, fixed or variable, lockup, region, chain, source, last-updated, last-verified, confidence, organic or sponsored. Deciding how a 30-day locked promotional rate compares to a flexible one is the thing customers are buying. Renaming endpoints would have created nothing.
Build for machine consumption first.
A structured API and an MCP server, so an assistant can query yield data directly with citable rows. This inverts the problem. Instead of competing with AI answers for the click, we become the source the answer cites.
Refuse to ship an LLM that emits yield numbers.
The obvious move was a research agent that answers rate questions in natural language. We did not build it. A model generating an APY figure in a financial context is a hallucination and liability risk, and the moment it is wrong the trust that makes the data saleable is gone. We return structured, sourced rows and let the customer's agent do the reasoning.
Instrument impressions, not just clicks.
Every comparison table now captures table views, row impressions, the position a row was seen in, the displayed rate at render time, filters and sorts, geography and device, and whether the listing was organic or sponsored. That converts a click log into a demand dataset, and it is what makes share-of-visibility and position-by-position conversion sellable rather than anecdotal.
Split into three products with three buyers.
Advertising sells distribution. Intelligence sells market-demand data. The API sells rate and product data. Keeping them separate matters because bundling intelligence into the ad product would cap that business at the existing advertiser base, and the people who most want to know what the market is doing are often the ones not yet advertising.
Publish the data-quality scorecard after the pipeline, not before.
A public freshness and accuracy page is an asset once the data is genuinely fresh. Shipped early it advertises the gap. We built the refresh pipeline first and exposed coverage statistics once they were something to stand behind.
Stay narrow.
We studied DeFiLlama, Elliptic, Token Terminal and Exa, and took one lesson each rather than their surface area. No TVL, DEX, bridge or NFT expansion. No compliance positioning. The category is crypto yield intelligence, and the way to win it is to be the most trustworthy source on yield rather than a thinner source on everything.
Execution
This is a change to what the company sells, executed as a sequence of shippable product changes rather than a relaunch. The public surface keeps running and paying while the data layer is built underneath it, because it is also the proof that the data is correct and current.
The work ran in a deliberate order. Normalised schema and a freshness pipeline first, because everything else depends on them. Then agent discoverability: llms.txt, machine-readable docs, copy-paste API examples, MCP tooling. Then the net-new products. Around 70,000 pages were rebuilt onto a single design system by collapsing them into seven templates rather than redesigning routes one at a time.
We led with the buyer already paying us. Providers on the marketplace are warm, identified and transacting, which makes them the right first customer for demand intelligence even though the eventual market is wider.
Outcome
The public coverage figures are the clearest evidence the pipeline is real:
| Coverage | |
|---|---|
| Rates normalised and monitored | 42,131 |
| Providers tracked | 57 |
| Assets covered | 620 |
| Rate updates in 24 hours | 31,168 |
| Median refresh across the yield surface | ~3 minutes |
The API, MCP server, yield copilot, publisher network and provider marketplace are live. The demand-intelligence dataset is the newest of the three product lines and is in its first weeks of capture.
Revenue, pricing and customer detail are commercially sensitive and are not published here.
What I learned
A change to the business model is a change to the product. The API only exists because someone sat down and specified the normalisation rules, and no amount of sales effort substitutes for that decision being made well.
The harder lesson is about instrumentation. The demand dataset was buildable for years and we did not build it, because clicks were enough to bill against and nobody asked what the denominator was worth. The most valuable thing in the business turned out to be a measurement we were choosing not to take.