If You Can't Measure Usage, You're Under-Billing

The problem

A software company sold access to two data-lookup features as part of its platform — but had no record of which customers were actually calling them, or how often. Without that record, there was no way to bill accurately, and no audit trail of what had been sent to or received from outside data providers.

The question

An engineer had already started a quick fix, bolting basic logging onto an existing database table. Was that fix good enough, or was there a better long-term answer?

The approach

The in-progress fix was reviewed against what the business actually needed it for — not just “log something,” but specifically: could this data support usage counting, a dashboard, and billing, all three? It couldn’t. Three schema design options were laid out with their real tradeoffs (query speed, database growth, data sensitivity, write volume), and one was recommended: a table that computed a “billable” flag at the moment each record was written, so billing later would be as simple as summing a column.

What I found

The quick fix would have solved the immediate visibility problem but silently failed the billing use case it was actually needed for — the two features couldn’t even be told apart in the data it captured.

What changed

A full design document specified the schema, the reasoning behind it, and a plain-language billing rule non-technical stakeholders could follow. It replaced the patch with a foundation that supported accurate per-use billing and a genuine audit trail — closing a gap that had been quietly costing the business revenue.