Internal Ops Platform

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.

• 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.

• 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.
• 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.

• Postgres as the serving layer rather than querying BigQuery directly, keeping latency low and costs predictable.
• Streaming responses for large result sets, avoiding browser timeouts and enabling progressive rendering on slow connections.
• Server-side caching and statement timeouts protect the serving database under a 10-minute sync cadence.
• Dagster assets as the single orchestration layer for all syncs, so scheduling, retries, and observability are consistent across every feature.
• Hierarchy-scoped filters enforced server-side, so the same endpoints serve store managers and executives without separate views.

• 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.