Every product org hits the same moment. Feedback is stacking up across calls, tickets, surveys, CRM notes, and Slack, and somewhere in that pile are the gaps that should decide the roadmap. An engineer looks at Claude, looks at the data, and says the reasonable thing: “we can build this ourselves.”
They’re probably right, they can build it. The real question is what it costs to build a version that still holds up three years from now.
We already covered the general framework for that decision on our build or buy page. This piece is the numbers behind it: what a real in-house build costs, at what scale the tokens stop being the small line item, and why we landed on a benchmark instead of a guess.
The short version: a mid-market org running this in-house lands north of $180,000 a year in dedicated engineering, on top of a raw data problem that costs up to 12 times more in tokens than it needs to. A Bagel license starts at $24,000 a year, tokens included. The rest of this article is where those numbers come from.
The raw feedback problem
Start with what a normal month of feedback actually weighs, in tokens, at mid-market volume.
| Feedback source | Tokens per unit | Monthly volume | Tokens / month |
|---|---|---|---|
| Call transcript (45 min) | 10,845 | 1,000 | 10,845,000 |
| Support ticket | 410 | 2,000 | 820,000 |
| Feature request (GTM / community) | 250 | 750 | 187,500 |
| CRM note (closed-lost, churn) | 250 | 500 | 125,000 |
| Slack channel (1-day threads) | 300 | 500 | 150,000 |
| Survey response | 200 | 750 | 150,000 |
| Total | 5,500 | ~12.3M |
Most build attempts dump all of it into a data lake, unfiltered, and that’s the first mistake. A data lake keeps everything, so every query re-reads everything every time, including the hour-long call that carries zero product gaps and the support ticket that’s really just a password reset with nothing to learn from.
We’ve written before about what happens when a company points a strong model at exactly this kind of raw, unfiltered data. Anthropic ran the experiment on their own internal analytics and published the number: 21% accuracy, even after confirming the model had read everything available. More data didn’t move it, a governed structured layer did, and that’s the same problem product feedback has, just with calls and tickets instead of SQL tables.
What a structured layer changes
The fix is cutting the noise before it reaches the model at all: extract only the feedback that carries a real product insight, normalize what’s left into a compact, readable unit, and query that instead of the lake.
Running our own production ratios against the table above changes the shape of the problem completely.
| Source | True insights / month | Ratio | Tokens |
|---|---|---|---|
| Call transcripts | 2,000 | 1:2 | 500,000 |
| Support tickets | 240 | 8.3:1 | 60,000 |
| Feature requests | 750 | 1:1 | 187,500 |
| CRM notes | 100 | 5:1 | 25,000 |
| Slack channels | 150 | 3.3:1 | 37,500 |
| Survey responses | 375 | 2:1 | 93,750 |
| Total | 3,615 | ~904K |
Same feedback, same month: 12.3 million raw tokens becomes roughly 904,000 insight tokens, about 12 times lighter. A 45-minute call that cost 10,845 tokens raw comes out the other side as roughly 500 tokens of validated insight with a link back to the source. Nothing is thrown away: the raw feedback stays retained, and what changes is that the set you query for an answer is only the part worth querying.
This is also where the numbers stop being abstract and start being a build decision.
What it actually takes to build this yourself
Most engineering estimates skip the part that matters, because “we can build it” and “we can run it for three years without anyone regretting it” are different claims.
Most internal AI builds don’t fail in the demo, they fail well after launch, and the industry numbers on this are stark. Gartner puts AI project failure at 85%, and RAND’s more recent research finds over 80% never reach production at all. For a system meant to unify calls, tickets, CRM notes, and Slack into one trustworthy source of product truth, the same handful of reasons show up every time: model drift as the underlying models change over months, reconciling feedback across a half-dozen disconnected sources into one consistent picture, SOC 2 compliance and PII handling once real customer conversations are involved, and getting product, engineering, and GTM to actually trust a system none of them built.
None of those four are problems you solve once, they’re problems you maintain forever, and each one carries a real cost:
- Integrations. Ten or more sources, each with its own API, its own auth, its own schema, each one breaking on someone else’s release schedule.
- Security. SOC 2 posture, role-based access, PII reduction, all mandatory the moment customer conversations run through an external model.
- Model verification. Every new model release means re-checking classification, clustering, and matching still hold.
- Governance. Product, GTM, and engineering all want their own view, their own taxonomy, their own cut of the same data.
- A dedicated engineer. At least one full-time hire, conservatively $180,000 a year loaded, or the project stalls from neglect.
That last point is the one that decides the math.
The bottom line
| Build in-house | Bagel | |
|---|---|---|
| Engineering | 1+ dedicated FTE, ~$180K/year | Included |
| Token spend | Unoptimized, against a ~12.3M token/month lake | ~12X optimized before the first query |
| Integrations, security, model upgrades | You build and maintain | Included |
| Governance across product, GTM, engineering | You build and maintain | Included |
| Annual cost | $180K+ plus tokens | From $24K plus usage |
The dedicated engineer alone runs more than seven times the license before either side spends a single token, and once you add the unoptimized token load from querying a raw lake instead of a structured one, the gap widens further. The full model behind this table, team size, feedback volume, and how the numbers move at scale, lives in our benchmark report.
Build vs buy? Get the numbers first.
See the real cost before your team writes a line of code.
Your team could build this, but building it means paying more to end up with less: fewer sources covered, a second product to maintain, and a full-time hire’s worth of cost before the first query runs. Bagel runs the Platform end to end, including Discovery OS for deep research and Bagel MCP for delivering it straight into Claude, Cursor, or Codex, all inside the Everything AI suite.
FAQ
Buying is cheaper in almost every scenario. A dedicated engineer to build and maintain an in-house system runs about $180,000 a year before token costs, against a Bagel license starting at $24,000 a year with the optimization already built in.
Unfiltered feedback (a full data lake of calls, tickets, and notes) forces every query to re-read everything, including the roughly 80% of content with no product signal at all. Extracting and normalizing insights at ingestion cuts the queryable token load by about 12 times for the same feedback set.
Anthropic connected Claude directly to their internal analytics data with no structured layer and measured 21% accuracy, even after confirming the model had read all available material. A governed, structured layer took that above 95%
Likely yes, in a prototype. The industry data on what happens after the prototype is less encouraging: Gartner puts AI project failure at 85%, and the recurring causes for this specific kind of system are model drift, multi-source reconciliation, SOC 2 and PII requirements, and cross-team trust, the four things that separate a demo from a system a company can run for years.
Conservatively, one dedicated full-time engineer at around $180,000 a year, plus unoptimized token spend. Under-resourcing this is the most common reason internal builds stall after the initial launch.
No. Bagel is the decision layer underneath them. It extracts and normalizes the product evidence, then serves it to Claude, Cursor, Codex, or any tool that speaks MCP, so your engineers and your agents are working from the same validated context instead of a raw data lake.
