Buy vs build your odds data layer: the upkeep decides it
OddsRelay · · Updated · 4 min read
Build your own odds data layer only if collecting odds is the product you sell and you can name who maintains it in year two. Otherwise buy. A capable team can ship a first version. The question is who keeps it complete once users depend on it.
What does building an odds data layer actually involve?
It is five jobs, and only the first one ever feels finished. Teams scope the build as "collect the prices" and meet the other four once users arrive.
- Collection: getting prices out of every book your users expect. For every book, the headline match-odds price is the small part. The deeper markets are where coverage goes partial.
- Event matching: mapping each book's and each exchange's name for a fixture and a selection onto one event, so a price is compared like with like.
- Exchange pairing: pairing each
backprice with a current exchangelayprice, and checking there is enough money on the lay side for the pair to be usable. - Freshness monitoring: knowing when a price went stale, a market dropped, or a book stopped returning selections.
- Being on call: coverage breaks at inconvenient hours, and someone has to notice and fix it. That is a rota and an escalation path.
Sources change without notice
A pipeline that returned complete markets in January can drift by March, whether or not you have time to follow the sites it reads. Nobody sends a release note. You find out when a user reports a gap, which is the most expensive moment to find out.
That makes collection a standing commitment, and the commitment grows with every book and every exchange you add. We describe the point where teams give this up in why teams stop building and buy a feed.
Scope the second year
A realistic build estimate is not "how long to the first paired price", but "how much engineer effort, every week, to keep coverage whole once the sources change". If you cannot name the engineers who own that work in year two, the build is not funded, however good the first version looks.
What buying gives back
Buying hands the collection, matching, pairing and upkeep to someone whose standing job they are. OddsRelay covers 140+ bookmakers, 60+ of them live in the UK & Ireland, bet365 included, paired against Betfair, Smarkets, Matchbook and BETDAQ. The six matched boards and raw are on every plan, and plans differ only in tokens.
- Time to market: an oddsmatcher or comparison product reads paired prices from its first call, rather than after the months an event matcher and exchange integration take to build.
- No maintenance treadmill: when a source changes, following it is the supplier's job, and your engineers stay on your product.
Some work stays yours. Each outcome is paired against exchange lay and liquidity-gated, and the rating and qualifying loss are simple arithmetic on the pair, at your own commission rate. The oddsmatcher widget shows them.
{
"name": "Arsenal",
"back": [{ "bookmaker": "william_hill", "price": 2.9, "link": null }],
"lay": [{ "exchange": "betfair_exchange", "price": 3.0, "available": 175, "link": null }]
}// commission is still yours to apply const rating = (outcome.back[0].price / outcome.lay[0].price) * 100
You also write the client. The feed is pull only, so you poll, sending each reply's ETag back as If-None-Match, and an unchanged board comes back as a 304 that costs no tokens. Every board carries its time in meta.processed_at (and the X-Processed-At header), and a matched envelope carries meta.last_seen per venue and sport, so you can check a price's age yourself (freshness explains both).
Build vs buy, side by side
| Dimension | Build your own | License a maintained feed |
|---|---|---|
| Time to first paired price | Weeks to months | Your first call once you hold a key |
| Exchange pairing | You build the event matcher and a liquidity check | Back and lay paired across four exchanges, liquidity-gated |
| bet365 | Yours to collect and pair | Included on every plan |
| Freshness | You build the watcher and the alerts | processed_at and per-venue last_seen on every matched board |
| When a venue breaks | Your rota, your weekend | The supplier's job. The coverage page shows each venue as live or interrupted. |
Effort only, not money.
What drives the cost of a feed breaks down where that effort concentrates, and how to choose an odds data provider covers what to check before you commit to any supplier. The comparison pages set suppliers side by side, with sources.
A checklist for your own situation
- Is odds collection your moat, or a means to something else? If the collection itself is what sets you apart, building can be right. If the data feeds your real product, buying keeps your effort there.
- Do you need bet365, paired against the exchanges? It is the book users check for first, so it has to be on your list from day one.
- How many books must you cover? A handful of books is a manageable build. A comparison-sized list, paired against several exchanges, is a standing operation.
- What does a stale or missing price cost you? If a wrong price breaks your users' trust, you are buying upkeep as much as data.
Check the feed against your own list
Before deciding, compare your must-have books with what the coverage page shows as live, and read the quickstart to see what your client would look like. If buying wins, request access.