ARData with Ale

Case study 02 / Analytics engineering / Dashboard product

Finance dashboards that show what the data can be trusted to say.

Finance users needed a shared view of revenue, returns and product launches without repeatedly opening reports or unknowingly relying on stale data. I was the primary builder of a read-only dashboard and kiosk platform for the CFO and Finance Business Planning team.

Outcome / Reduced recurring manual reporting effort and made data freshness and gaps visible to finance users. Explore the anonymized interactive demo ↗

My contribution
Primary builder · UX, models, SQL, APIs and reliability
Primary users
CFO · Finance Business Planning
Project status
Revenue, Returns and New Product Launch in active use

01 / The problem

Finance Analytics Platform

A dashboard can look current while serving old data. Finance reporting also becomes misleading when revenue, settlement, returns or differently grained records are treated as interchangeable.

Reporting data flows through PostgreSQL and a read-only API to desktop and kiosk views. Calculation rules preserve metric meaning, and freshness states travel with the displayed data.

  1. Upstream reportingExisting pipeline maintained by a Data Engineer supplies the reporting data.
  2. Model & calculatePostgreSQL transformations keep reporting windows, source grain and metric definitions explicit.
  3. Serve with contextNode / Express APIs provide read-only data, cache provenance and the last successful payload.
  4. Make status visibleReact dashboards and kiosk views show freshness, mapping gaps and safe degraded states.
Architecture redrawn for this case study with generic system labels. Technology: React / Vite · Node / Express · PostgreSQL · Recharts · Docker · AWS EC2 · Cloudflare Access / Tunnel · systemd · GitHub Actions.

02 / See the work

A dashboard that keeps freshness in view

Synthetic dashboard concept. The values and reporting states below are fictional examples, not a live view or a measurement of platform performance.

Finance Analytics Platform

Illustrative reporting view

Synthetic data · Not a live dashboard

Revenue view · example period

124,000 fictional currency units

  • Physical returns18 units
  • Refunds without a return6 cases
  • Unmapped productReview required

Different outcomes remain separate. An unavailable value is not displayed as zero.

Data confidence

  • RevenueCurrent
  • ReturnsCached · earlier refresh
  • Launch mappingIncomplete

If a source fails, retain the last successful payload and clearly label its status.

Recreated specifically for this portfolio. No employer screenshots, source records or financial results are shown.

Before / silent ambiguity

An unavailable source appears as zero, or an old payload is displayed without a freshness warning. The viewer cannot distinguish missing data from an actual result.

After / explicit confidence

Show unavailable values, label cached or stale results and retain mapping warnings beside the relevant measure.

03 / Technical judgment

The decisions behind the result.

  1. Preserve metric meaning

    Gross sales, net revenue, settlement and return outcomes remain distinct. Product and SKU measures are not added together.

  2. Read a consistent snapshot

    Read-only snapshot transactions avoid combining different transformation batches in a single response.

  3. Fail visibly and safely

    Caching, retry handling and last-known-good payloads keep a useful view available while exposing freshness and fallback states.

  4. Design for unattended use

    Kiosk rotation, pause controls and navigation support shared displays. Protected access and API boundaries keep database credentials out of the browser.

View a simplified processing pattern
# Illustrative pseudocode — not production source
if source_is_available:
    payload = read_consistent_snapshot()
    retain_last_success(payload)
    show(payload, freshness="current")
else:
    show(last_success, freshness="cached")

# Missing values stay unavailable; they do not become zero.

04 / Ownership & impact

What I delivered, and what changed.

My work and collaboration

I built dashboard UX, data models, SQL transformations, API services, calculation rules, reliability controls and delivery coordination.

A Data Engineer maintained the upstream e-commerce pipeline. A Backend Developer supported deployment to AWS EC2. The CFO and Finance Business Planning team were the primary users.

Outcome

Revenue, Returns and New Product Launch views were in active use. The platform reduced recurring manual reporting effort and improved refresh resilience through explicit caching, retries and last-known-good behavior.

Qualitative outcomes and usage status reflect my project account. Illustrative values above are not impact metrics.