Why Bonfire Analytics Switched from Tavily to TinyFish
At a glance
- Company: Bonfire Analytics, a healthcare intelligence platform for companies selling into healthcare
- Use case: Entity resolution, matching messy CRM records against Bonfire's healthcare database
- Previously: Embedding-based similarity search, then Tavily for web lookup
- Now: TinyFish handles all of Bonfire's entity resolution web search
- Why: Better accuracy at a fraction of the cost of per-query search
The problem
Bonfire Analytics is an intelligence platform for companies that sell into healthcare, or as founder Jaya puts it, Clay for healthcare. Bonfire integrates directly with customer CRMs like HubSpot and Salesforce, connecting a customer's accounts to Bonfire's own healthcare data. That data is entered by people in a hurry, so it rarely lines up.
A sales rep types "BMC" instead of Boston Medical Center. Someone logs a satellite clinic address instead of the main hospital. An address gets typed wrong, or just doesn't follow whatever convention the database uses. None of it matches cleanly, and in healthcare a bad match means attaching the wrong claims history to the wrong organization.
The first approach: embeddings
Bonfire started with embedding-based similarity search. Embed the customer's CRM records, embed Bonfire's data, look for the closest matches.
It worked well enough, but it was really a workaround for a cost problem. Web search at that scale was expensive, so embeddings looked like the cheaper option even though similarity scores are a fuzzy way to answer "is this the same organization or not."
The second approach: resolve against an identifier
Once web tools got cheap enough to run at volume, Bonfire moved to a better method. Instead of scoring similarity, resolve against a hard identifier.
Every healthcare practitioner and organization in the US has an NPI, a National Provider Identifier. A large organization may hold several, but finding one is enough to anchor the match. So Bonfire changed the workflow: for each messy account or contact, find the NPI on the web, then map that NPI back to Bonfire's data.
Accuracy improved over the embeddings approach, and the web agent went from a nice-to-have to a core part of the pipeline. Every new Bonfire customer now runs through it during onboarding.
Why they chose TinyFish over Tavily
Bonfire ran this workflow on Tavily first. Cost was a real issue.
Entity resolution isn't an occasional lookup. It's a full pass over a customer's CRM every time a new customer comes on, so per-query pricing means the bill scales with how much data that customer has and how messy it is. Bonfire runs millions of lookups a year through TinyFish, and at per-query rates that isn't a workflow anyone runs freely. Bonfire was rationing how much web lookup it could do, on a workflow where more lookup is the whole point.
TinyFish includes web search at no additional cost on higher plan tiers. That removed the constraint rather than reducing it, and Bonfire stopped treating web lookup as something to ration.
Quality held up through the move. On Bonfire's own testing, TinyFish came out on par with Tavily on search quality, and the workflow it made affordable resolves entities more accurately than anything Bonfire had run before. The team now runs entity resolution entirely on TinyFish.
"We've tried a few different tools. For entity resolution, TinyFish has been the most cost-effective and the best method for us to use."
Jaya, Bonfire Analytics
What's next: provider addresses
Entity resolution is the part that's shipped. The harder problem is still in progress.
Provider directories in the US are badly out of date. Published studies have found that a large share of health insurance directory information is inaccurate at any given time. Doctors work across a hospital, a clinic, and sometimes two or three other locations, and the directories rarely keep up.
Bonfire is building a workflow that pulls current provider addresses off the web and cross-references them against claims data. If an address appears on the web and the claims data shows recent billing from that organization, it's a high-confidence address. TinyFish finds the provider URLs, and Bonfire's own extraction layer parses out the address and other details.
It's a large-scale problem that needs a lot of web coverage to solve, and it's the kind of workload TinyFish is built for.
Building something that needs the web as a reliable data layer?
