TL;DR - NutriFinder is the friendly face, but the real project sits one layer down: OSDb, the Open Supplements Database - an open, structured, trustworthy reference for sports-nutrition and supplement data. IMDb for movies, Open Food Facts for groceries, OSDb for the stuff in your race vest. It already powers every comparison on NutriFinder; what’s next is a public API, wider coverage, and more apps on the same data layer. This is the story of why it exists and where it’s going.
Most people who find my work meet it through NutriFinder, a site that helps endurance athletes pick the right gels, drinks, and electrolytes by the numbers - I wrote about it here. That’s the part with a friendly face. But if you ask me what I’m actually building, the honest answer sits one layer down, in the boring, unglamorous, weirdly addictive problem of the data itself. That layer has a name: OSDb, the Open Supplements Database. This is the story of why it exists and where it’s going.
What OSDb Is
OSDb is meant to be the open, structured, trustworthy database of sports nutrition and supplement products. The mental model I keep coming back to is IMDb for movies or Open Food Facts for groceries: one canonical place where every product has a clean record, the numbers are normalised, and anyone can look them up and trust them. Not a store, not a brand’s marketing page, not a forum thread. A reference.
Today that database already exists and already does real work: it’s the engine underneath NutriFinder. Every comparison, every leaderboard, every head-to-head page you see on the consumer app is reading from OSDb. NutriFinder is how an athlete touches the data. OSDb is the data.
Why I’m Building It
The reason is the same frustration that started NutriFinder, followed one level deeper. When I first tried to compare energy products on their actual nutrition, I discovered there was no good source of truth. The numbers live in tiny sachet print, in inconsistent PDFs, in marketing copy that rounds in the brand’s favour, in units that never match between companies. There is no canonical record for “this gel, this flavour, these grams of carbohydrate”.
So everyone rebuilds it. Every app, every coach with a spreadsheet, every brand comparing itself to a rival, every researcher: all of them re-scrape and re-clean the same data over and over, badly, in private. That’s an enormous amount of duplicated effort spent recreating something that should exist once, in the open, and be shared. I kept thinking: this should be infrastructure. Someone should just build the clean layer and let everything else stand on top of it. OSDb is me deciding to be that someone.
What It Actually Does
Underneath the vision it’s a fairly concrete system. OSDb holds canonical product records with normalised fields: carbohydrate, sugar, sodium, caffeine, protein, price per portion, format, and the rest of the attributes that actually matter when you’re choosing what to put in your body mid-effort. Keeping that current by hand across dozens of brands would be miserable and error-prone, so the data is refreshed by an automated pipeline: a scraper built on Playwright, with a language model doing the messy work of reading a brand’s page and turning inconsistent human text into a clean, structured record. That pipeline runs on a schedule and is where a lot of the real engineering quietly goes.
On top of the data sits an API. Right now it serves NutriFinder, but it was designed from the start to be consumable by more than one thing: other apps, brands who want to see and correct their own records, coaches, researchers, anyone who needs sports-nutrition data they can actually trust. The open-data angle is not a marketing garnish, it is the point. Open Food Facts showed that a transparent, community-shaped database can become the reference for an entire category. I want OSDb to earn that same role for supplements.
Where It’s Heading
Three directions, roughly in order of how soon they matter.
First, opening the door. The API exists but it’s not yet a public front door with docs and access anyone can sign up for. Turning it into one, properly, is the step that makes OSDb a thing in its own right rather than a private backend.
Second, breadth. The endurance core is where I started because it’s what I know, but the database is built to grow past gels and drinks into the wider supplement world.
Third, a second face. NutriFinder serves endurance athletes, but the same data layer could just as easily power a companion for strength and gym athletes: a different brand and palette on top of the same OSDb backend. That’s a deliberate architecture choice, not a someday-maybe: build the data once, let many apps bloom on it.
Where It Actually Stands
Let me be straight about the stage, because it’s easy to describe a vision in a way that sounds bigger than the reality. OSDb today is real and it’s working, but it’s working quietly, as the engine of one consumer app. It’s not yet a launched, open, sign-up-and-build-on-it product. This is a setup phase, done deliberately and in the right order: prove the data is good by shipping something people actually use, then open it up. It’s an indie effort run lean, not a funded data company with a sales team. What’s next is the unglamorous, essential work of widening coverage, hardening the pipeline, and getting the database good enough that opening it up is something to be proud of rather than apologise for.
If This Resonates
If you build in this space, or you’re a brand who wants your products represented accurately, or you just think an open reference database for sports nutrition should exist, I’d love to hear from you. The most useful thing at this stage is not applause but pressure: tell me what you would want to query, what you would build on it, where the data would need to be better before you would trust it. I’m building this in the open, one clean record at a time, and the whole point is that it’s not meant to be mine alone. If that sounds like a problem you’re also carrying - a dataset everyone rebuilds in private, an API that deserves a front door - let’s talk.