Finlo

Problem. Each site turns on a different mix of revenue streams (parking, penalties, tickets, bus, billing) and payment methods, and some ran different app versions. So both which numbers exist and how the raw records add up changed from site to site. There was no single fixed shape to total against.

Approach. I drove the dashboard off each site's own configuration. It builds its list of stat sections from the site's flags and only shows what that site actually uses, including handling the older app version's differences. For the totals, the daily records have keys that aren't known ahead of time (per vehicle category, per operator, per payment mode, per stop), so the code walks each record, works out whether it's a single number or a bucket of more numbers, and folds it up, turning ids into names along the way.

Outcome. One dashboard codebase covered every kind of site without a separate build per client, and the same engine handled a second record shape for events.

Problem. A finance dashboard that's slightly wrong is worse than none, and operators needed exports shaped differently per client. Early on the totals didn't always reconcile, including a bug that double-counted some amounts.

Approach. I chased the reconciliation issues back to their source so the totals matched the underlying records, and built the exports for Excel and PDF with a configurable option and per-client templates rather than hard-coding each one.

Outcome. Operators could pull correct, client-shaped reports themselves without an engineer in the loop every time.