Build vs buy: DIY usage metering

Every engineer who has looked at a usage-billing product has had the same thought, and it is not an unreasonable one: this is a table of events, a join against a rate card, and a sum. A fortnight, maybe three weeks.

That estimate is correct for the prototype. This is what the prototype does not include, written by people who have built it more than once.

What the fortnight buys you

Events land in a warehouse. A scheduled job joins them to a rate card and writes amounts. A dashboard sums the amounts by customer. It works, the numbers look right, and everyone is pleased.

It works because the first fortnight only ever meets the happy path. Every event arrives exactly once, in order, with a sensible timestamp, matching a rate that has never changed.

What arrives afterwards

Duplicates

A client retries. A queue redelivers. Someone replays a day to backfill a gap. Now you need a deduplication key, a window over which it applies, and a decision about what happens to a duplicate that arrives after the window closes.

Late and out-of-order events

A switch was offline; a day of records arrives at once, timestamped yesterday. Your nightly job has already run and produced a total that somebody has looked at. You now need re-rating, and a rule about whether a closed period can reopen.

Plan changes

The rate card changes on the 15th. Your join is against the current rate card, so last month's totals silently change. Fixing this means versioning the rate card by effective date and joining on the event timestamp — which is a schema change, a backfill, and a careful migration of everything already computed.

Rounding

Someone notices the invoice total and the sum of the line items differ by a few pence. This is rounding applied per row instead of once at the end, and correcting it changes historical figures, which means explaining to finance why last quarter moved.

The question you cannot answer

A customer asks why one specific charge is what it is. Your warehouse has the events and the totals, but not the working — which rate matched, which increment applied, which version was live. Recording that is another schema change, and it does not apply retroactively.

The ongoing cost

The build is a one-off. The maintenance is not. A metering pipeline is a permanent claim on whoever understands it, and a risk on the day they leave. Warehouse costs move with query volume, which means your analytics bill grows every time somebody becomes curious about their own data.

There is also the piece that almost never gets built: reconciliation. Checking what your suppliers charge you has the clearest payback of anything on the list, and it is always next quarter's project, because it is nobody's job.

When building is the right call

Genuinely, sometimes it is. Build if your rating rules are simple and stable — a flat rate per unit, no increments, no minimums, no prefix matching. Build if usage billing is your product rather than an operational function of it. Build if you already have a team who owns this domain and enjoys it.

And if you have already built it and it works, do not replace it out of tidiness. The most sensible move in that position is usually to leave the metering alone and add reconciliation, because that is the part you almost certainly do not have.

How to decide

• Write down your rating rules in full. If the list runs past a page, the fortnight estimate is wrong.
• Ask who owns it in three years, and what happens if that person leaves.
• Cost the warehouse at the query volume you want, not the volume you have.
• Ask whether anyone will ever build the supplier audit. Be honest.
• Try to reproduce one line of last month's invoice from first principles.