LiveLedger is a small piece of internal financial-tracking software we built for a customer running on a third-party game-service-provider platform. Their checkout, micro-transactions, and customer billing all happen inside that provider's API — and the only "reporting" the provider exposed was raw JSON on a developer dashboard. Reading it meant squinting at nested objects to figure out what last week looked like, never mind testing whether a new offer or a pricing tweak was actually moving revenue.
What was wrong
The customer had visibility into transactions, technically, but no way to answer questions with them:
- "How did last week's promo do compared to the week before?"
- "Which products are quietly carrying the storefront?"
- "Which customer segments respond to which offers?"
The provider's dashboard was outdated, the JSON was hard to parse by hand, and there was no path to roll it up over time without copy-pasting into spreadsheets — fragile, unscalable, and too painful to do often enough to matter.
What we built
A small Node.js service that:
- pulls historical purchase + customer data via the provider's REST API on a schedule
- subscribes to the provider's webhooks for live purchase events as they happen
- normalizes both feeds into a single, time-series-friendly schema
- writes everything into a Cassandra cluster — append-heavy, easy to scale out as transaction volume grows
On top of that sits a deliberately simple local-only web app: a couple of pages of charts and tables for income over time, top products, customer-segment breakdowns, and side-by-side comparisons across arbitrary date windows. Local-only is intentional — the customer's billing data stays on their machine, not exposed on a public hostname.
What it gave them
The customer went from squinting at raw JSON to opening a chart and getting an answer. They use it for:
- General income tracking — month-over-month, product-by-product
- Testing the waters on new offers, pricing tweaks, or seasonal promotions with a real before/after read
- Customer mapping — seeing which segments buy what, so the next offer is informed by who actually responded to the last one
The system was handed over and has continued running in production since. Cassandra has plenty of headroom for years of additional growth without a re-architecture.
The customer's game-service-provider exposed transaction data only as raw JSON on an outdated developer dashboard — technically visible, but not answerable. Questions like "how did last week's promo do?" or "which products are quietly carrying the store?" meant hand-parsing nested objects, and rolling it up over time meant fragile copy-paste into spreadsheets. The reporting friction was the reason they weren't running half the experiments they wanted to.
A small Node.js service ingests the provider's REST API on a schedule and subscribes to webhooks for live purchase events, normalizes both feeds into a time-series-friendly schema, and writes them to Cassandra — append-heavy and easy to scale as transaction volume grows. A deliberately simple local-only web app sits on top: charts and tables for income over time, top products, customer-segment breakdowns, and side-by-side date-range comparisons. Local-only is intentional — the billing data never leaves the customer's machine.
Squinting at raw JSON traded for opening a chart and getting an answer. The customer now uses it for general income tracking, before/after reads on new offers and pricing tweaks, and customer-segment mapping that informs the next offer with how the last one actually performed. The system was handed off to them and has been running in production since, with plenty of Cassandra headroom for years of additional growth.
Most of these started with one paragraph.
Send yours and we’ll tell you whether we’re the right fit before either of us spends another minute on it.