arthurblattman.dev
← Selected work
Case Study · Principal Engineer, solo · 2025 - 2026

Internal Ops Platform

Replaced Power BI as the company's BI layer and retired hundreds of license seats, with Retail, Franchise, and Finance on one source of truth.

The in-house BI and operations app that replaced Power BI for Retail, Franchise, and Finance.

Built and operated by one engineer2025 - 2026React + Tremor + visxFastAPIdbt + Dagster + PostgresRetail, Franchise & Finance
100s
of Power BI license seats retired
10 min
from sale to intraday revenue, store by store
4
repositories held to one shared pattern
1 week
to deliver the Franchise KPIs suite end to end
01

Context & Goal

The business operates across retail stores, franchise locations, and e-commerce, with operational reporting spread over Power BI and one-off exports. This purpose-built internal app replaced that layer with authoritative, live data: a React application backed by streaming FastAPI endpoints, serving Retail Operations, Franchise, and Finance from a single source of truth.

It is the serving layer of the GCP Data Platform.

02

The four layers

Every feature in the app is built on the same four layers, which is why a new report is a known set of changes rather than a new design.

01
dbt models in BigQuery

Business logic lives here once. No duplicated definitions between the warehouse and the app.

one definition
02
Dagster sync to Postgres

Orchestrated syncs land the models on a Cloud SQL replica, so scheduling, retries, and observability are consistent across every feature.

every 10 min
03
Streaming API

FastAPI endpoints stream large result sets, with server-side caching, statement timeouts, and hierarchy-scoped filters enforced server-side.

progressive
04
React front end

Tremor and visx dashboards. A new report becomes a known set of changes rather than a new design.

4 repositories
The app reports its own usage back to BigQuery, where dbt sessionizes it into a report surfaced inside the app
03

Results

  • Replaced Power BI as the company's BI layer, retiring hundreds of paid license seats.
  • Retail, Franchise, and Finance operate from one source of truth instead of separate exports and reconciliations.
  • Intraday revenue is visible within 10 minutes of the sale, store by store. Under Power BI it refreshed on scheduled dataset syncs.
  • Franchise owners get a full-month-projected Daily Need figure, turning month-end shortfalls into a daily target they can act on.
  • No duplicated business logic between the warehouse and the app, because every feature shares one four-layer pattern.
04

What I built

Data modeling, orchestration, backend services, and the React UI.

Live Sales

Intraday revenue for every store on a 10-minute POS-to-dashboard loop, with a day-pulse drill-in for hour-by-hour store activity.

Sales Journal

Streaming /lines and /search endpoints feed a live revenue view with is_new_customer enrichment, a store-activity heatmap, and hierarchy-scoped filters (brand, region, store). Response streaming replaced buffered payloads after performance testing.

Inventory Daily Movement

Ingests NewStore POS movement facts from the dbt warehouse, synced via Dagster to Postgres, enriched with NetSuite parent (matrix) item data, and surfaced as a searchable report.

Franchise KPIs dashboard

Full-month-projected Daily Need calculation built on dbt models, Dagster-synced to a Postgres replica, and delivered as a React dashboard. The same initiative wired a Klaviyo text-in opt-in list for franchise owners.

Retail Referrals dashboard

Surfaces associate attribution data from the data warehouse for Retail Ops and team-member performance review.

Usage telemetry

The app reports its own usage events to BigQuery, dbt sessionizes them, and a Dagster sync surfaces a usage report back inside the app, closing the loop on which dashboards actually get used.

One shared data pipeline

All features share the same four-layer pattern: dbt models in BigQuery, Dagster-orchestrated sync to a Postgres replica, streaming API endpoints, React front end with Tremor and visx. No duplicated business logic between the warehouse and the app.

05

Key decisions & tradeoffs

Each of these bought something and cost something. The cost is the interesting half.

Postgres as the serving layer rather than querying BigQuery directly.

Keeps latency low and costs predictable.

TradeoffEvery dashboard reads a replica, so freshness is bounded by the sync cadence.

Streaming responses for large result sets.

Avoids browser timeouts and enables progressive rendering on slow connections.

Server-side caching and statement timeouts.

Protects the serving database under a 10-minute sync cadence.

Dagster assets as the single orchestration layer for all syncs.

Scheduling, retries, and observability stay consistent across every feature.

Hierarchy-scoped filters enforced server-side.

The same endpoints serve store managers and executives without separate views.

06

Scale & Delivery

  • Single engineer across all layers: data modeling, orchestration, backend services, and React UI.
  • Franchise KPIs suite delivered across four repositories in a single week: dbt models, Dagster sync, React dashboard, and Klaviyo opt-in wiring.
  • Four repositories held to one shared pattern, so a new report is a known set of changes rather than a new design.