The HN Ask thread (HN 44042273, 2025-05) was titled "Did you build or buy your customer analytics?" The thread went sideways immediately because the question conflated two different artifacts: an internal analytics dashboard (what your team uses to understand customer behavior) and a customer-facing usage dashboard (what the customer sees inside your product). They are different jobs, different tools, and getting them mixed up costs weeks.
This article is about the second one — the dashboard inside your product that the customer opens to see what they used and what it cost. The internal one is a separate problem.
The three numbers a customer actually wants to see
The customer-facing usage dashboard is not a BI tool. The customer wants three numbers, in this order:
- What I used this period. One number, current-period-to-date.
- What my plan includes. The quota baked into the plan.
- What overage looks like. The current cost if billing closed now, broken down: included + overage at rate $X.
That is the dashboard. Three numbers, one bar showing progress through the quota, one line showing the overage rate. Anything more is the team's curiosity speaking, not the customer's need.
What to leave out
The temptation is to show charts. Resist. Specifically:
- Time-series of consumption ("here's your usage by day") — customers do not optimize their behavior off a chart. They look at the bar.
- Per-feature breakdowns ("AI prompts cost X, exports cost Y") — useful in version 2 if customers ask for it. Do not ship in version 1.
- Forecasts ("at your current pace you will spend Z this month") — sounds helpful, is anxiety-inducing, and is wrong as often as right.
- Comparisons to other customers ("you use 30% more than average") — invasive and irrelevant.
Customer dashboards that win are surprisingly small. The dashboards that lose are full of analytics that nobody asked for.
The data shape behind it
Three sources feed the dashboard:
- The metering service's "current period state" endpoint. Returns: customer ID, period start, period end, units consumed, quota included, overage rate, projected total. This is the same endpoint your invoicing pulls from; consistency between dashboard and invoice is the whole point.
- Plan metadata from your billing system. Quota, overage rate, pricing tier name. Stripe Subscription or whatever you use.
- Optionally, the last 30 days of daily totals if you ship the time-series chart in v2.
For makers using a metering service, this is a single API call per dashboard render. Cache it for sixty seconds; the customer will not notice. If you are running your own meter, this is the moment where the consistency-of-your-pipeline gets tested; the dashboard and the invoice must show the same numbers.
Where to put the dashboard in a no-code stack
If your customer-facing product is built on AppElixir or any modern no-code platform with dashboard views: the usage dashboard is a dedicated view, accessible from the user's account menu. The view embeds a single block that calls your metering service's per-customer endpoint and renders the three numbers plus the bar.
The HTML block (or its no-code equivalent) is maybe 200 lines. The styling matches the rest of your product. Iframes from third-party analytics tools are a tempting shortcut and a long-term mistake — your product feels stitched together when the usage tab looks like a different application.
The build-or-buy framing that does not apply
The "build vs buy" debate from the HN thread is about analytics tooling (Mixpanel vs DIY, Looker vs Metabase, etc.) for the team-internal use case. The customer-facing usage view is a different job. You almost always "build" it (in your no-code platform or your product UI) because:
- It needs to live inside your product, not in a popup or iframe
- The data shape is tiny (three numbers + a bar) and not worth a third-party rendering tool
- Your customers will not log into a separate URL to check their usage
The exception is if your metering provider ships a white-labeled embedded view. UsageBox and a couple of competitors offer this as an iframe-friendly component. Use it if your product is already iframe-friendly; otherwise replicate the three numbers in your native UI.
The one moment that earns its keep
The dashboard's value is concentrated in one moment: the customer checks the bar, sees they are at 78% of quota, and decides to upgrade or moderate. That moment removes the support ticket that would have arrived three weeks later as "I did not realize I was using so much." Every customer who self-throttles or self-upgrades pays back the entire engineering effort.
This is the underrated half of usage-based pricing. The meter counts the events; the dashboard turns the count into a customer decision. Without the dashboard, the meter is a billing system. With the dashboard, the meter is a product feature.
What I would actually do
- Build the simplest version first. Three numbers, one bar, one overage line. Ship.
- Add a time-series chart in v2 only if customers ask. Most never will.
- Keep the dashboard in your product, not in a third-party tool. The customer should not leave your app to check what they used.
- Match the invoice exactly. If the dashboard says 13.5 and the invoice says 14.2, you have an internal-consistency bug that will eat your support time.
The honest framing: the customer-facing usage dashboard is the smallest piece of usage-based billing and the one that converts the most. Build it last; ship it small; never skip it.