"Why can't I build this myself with Claude Code?"
We get some version of that on most build-versus-buy calls, and it’s a fair question. Pull usage from a provider API, sum the tokens, multiply by a price, chart it. An engineer could ship that in a sprint. We’re not going to pretend otherwise.
The internal dashboard usually works fine for about six months. Then the person who built it moves to another team, a provider changes a usage endpoint, and the numbers stop matching the invoice.
What follows comes from customers and prospects who walked us through what they built, what it cost them, and what broke.
What you are actually signing up to build
The weekend version tracks one provider. Your stack has more than one, so here is what shows up on calls when teams describe what they already built.
- Provider integrations, plural. One team listed Gemini Code Assist, Windsurf, Cursor, and Snowflake Cortex in a single breath before calling the combined picture "very, very convoluted." A FinOps lead at a large software company had 30 lines of business and five cloud providers to reconcile, with AI spend scattered across all of them.
- Price sheet drift. Model prices change, tiers change, caching and batch discounts change, new model families launch. Every change is a silent data-quality bug in your dashboard. Nobody puts this on the build estimate.
- Attribution, which is the hard part. Token counts are easy. The work is tying them to a user, an agent, a team, a customer, or a Jira ticket. An engineering leader at a security company framed the real requirement clearly. "You burned 500,000 tokens for this Jira project. What did I get for that?" A FinOps team at another company tracked roughly 50,000 AI SKUs and knew its infrastructure spend precisely, yet could not name what was driving any of it.
- Tool and non-token spend. Agents call vector stores, search APIs, and databases. One team described agents querying Snowflake, where the cost lands on the Snowflake bill and never traces back to the agent that triggered it.
- Enforcement. A founder who ran security at a large procurement company was blunt about the gap. Providers have budgets and alerts. "What none of them have is the ability to cap it." Their alerts report spend after it clears.
- The enterprise tail. SSO, role-based access, data retention, PII handling, audit trails, chargeback logic, an API so finance can pull it. This is the part that turns a sprint into two quarters.
The tax nobody prices in
The build estimate covers one quarter. The maintenance runs for as long as you use the thing.
Provider APIs change, and usage endpoints change format. New model families arrive with new pricing dimensions. Your coding assistant vendor gets acquired and the reporting moves. Each event is a ticket that competes with your actual roadmap, and it always loses until the CFO asks a question nobody can answer.
A product finance leader at a large data platform walked us through the build path from the inside. Their default would be to do it themselves, which could work, but it would take a while, it might not land the first time, and it would mean fighting engineering and data science for bandwidth at every step.
A VP of engineering who had already built it was more direct. "We have our own internal kind of kludged together thing that does some of what we need. It doesn't do it elegantly and then it's another thing to maintain."
That is where most homegrown tools end up. They work well enough to keep, they stay about 70 percent finished, and they get owned by someone who never signed up to own them.
The cost of being late
While the internal tool is in progress, spend keeps moving. A CMO told us about a $32,000 Bedrock bill that arrived a month after the spend happened. Their COO added the part that stings. "We could have cut that off immediately on like day two had we had any visibility into this."
A misconfigured key at a very large software company burned roughly $90,000 in a single week. A partner working with state agencies expects the same pattern across public sector deployments, where one wrong setting becomes a million dollar bill inside a month.
Every one of those bills landed while somebody's internal tool was still sitting in a backlog.
What the buy path collapses
Building this is possible. Buying it turns a multi-quarter project into a few days of instrumentation, and hands the provider churn to a team whose full-time job is absorbing it.
A CIO at an IT services firm drew the line for us. "I don't want to build a reporting engine to ingest the data, build SDKs into the environments to get what the developers are doing." A principal engineer at a support platform running an eight-figure AI run rate landed in the same place, wary of building over buying and reluctant to spend the effort when something workable already exists.
Even the teams that finished something rarely defend it. One engineering group showed us the API-key view they had built and described it as not as nice as ours, but there.
Where we land
We ship open-source SDKs and middleware for Python, Node, and Go, and the rest of the org is public at github.com/revenium.
You can read exactly what we capture before you send us anything.
The SDK setup docs cover the provider wrappers and the full field reference, and if your stack already emits OpenTelemetry you can skip the SDK and point OTLP at us instead.
Drop it in, get per-user, per-agent, per-customer cost with outcomes attached, and set real limits rather than alerts that arrive after the money is gone.
If you want to build it, build it. Just price the whole thing first. The integrations, the drift, the attribution model, the enforcement, the audit trail, and the engineer who maintains all of it for the next three years.
