Know which customers lose you money

The idea

A service that sits beside your application, tags every expensive operation with the account that caused it, and reconciles those tags against your actual vendor invoices at the end of the month. The output is one number per customer: what they paid you, what they cost you, and the gap. It is not a cloud cost dashboard — those tell you that EKS cost $9,400. This tells you that Northwind Plc cost $412 of that $9,400 while paying you $199.

Why build this

Every usage-heavy SaaS has customers it is quietly subsidising. The ones running hourly syncs, the ones whose CSV exports are 400MB, the ones whose support agent loops an LLM twelve times per ticket. Finance sees one blended COGS line and product sees none of it, so pricing gets set on vibes and the worst accounts are invisible until someone builds a spreadsheet by hand.

The reason to build it now is that the cost side became attributable. Cloud providers publish hourly usage reports with resource tags, most infrastructure vendors expose per-key usage endpoints, and LLM APIs return exact token counts on every response. The data exists; nobody is joining it to a customer id. Meanwhile, the LLM line item has turned variable cost from a rounding error into the biggest thing on the bill, which makes per-account margin an urgent question rather than a finance-team curiosity.

Stack sketch

• Instrumentation: a thin SDK (TypeScript and Python) wrapping OpenTelemetry, emitting a span per billable operation with account_id, a unit, and a quantity. Anthropic and OpenAI wrappers read usage off the response automatically.
• Ingest: OTLP into a collector, then batched writes to ClickHouse. Raw events are cheap to keep and you will want to re-run attribution when the model is wrong.
• Cost side: nightly pull of the AWS Cost and Usage Report from S3 (or GCP billing export to BigQuery), plus vendor usage APIs — Stripe, Twilio, Anthropic, Snowflake.
• Attribution engine: dbt models in ClickHouse that split each invoice line across accounts by measured share, with an explicit unattributed bucket. Never silently spread the remainder.
• Revenue side: Stripe subscriptions and invoices, so margin is real dollars, not list price.
• Frontend: FastAPI plus a plain React table. The primary artifact is a sortable list of accounts by margin, and a CSV export finance will actually open.

Scope for v1

• One cloud provider (AWS) and two vendor integrations.
• Attribution for three cost types: compute time, object storage bytes, and LLM tokens.
• Monthly grain only. No real-time budget alerts.
• A hard rule that every invoice dollar lands somewhere, including unattributed, and that number is shown on the dashboard rather than hidden.
• Out: forecasting, pricing recommendations, anomaly detection, anything resembling a FinOps suite.

Where it could go

The obvious second act is closing the loop into product. Once margin per account is trustworthy, the same events feed usage-based billing — you already have metered quantities per customer, which is the hard part of shipping consumption pricing. Selling "we will help you introduce a usage tier" is a much easier conversation than selling a reporting tool.

The other direction is per-feature rather than per-customer. The same spans, grouped by operation name instead of account, tell you which feature carries the COGS. That is the number that decides whether an expensive AI feature belongs on the free tier, and today most teams guess.

Watch out for

Attribution is a modelling exercise, not a measurement, and the fastest way to lose a customer's trust is a number they cannot reconcile against their AWS bill — so make every figure drillable down to the underlying invoice line and show the unattributed share honestly.