Data foundation
Budget tables
Vendor spend
Employee/headcount model
Software cost model
Flagship case study
BudgetDB: an operations analytics warehouse for executive decisions.
BudgetDB is the anchor system: a SQL/Postgres decision layer for budget, software spend, headcount allocation, QA, and leadership reporting.
Business question
Where is operational spend concentrated, and what should leadership prioritize?
The project reframes raw operational and budget data into a reusable reporting system: cleaned tables, analytics-ready views, QA checks, and executive outputs.
BudgetDB code
1CREATE VIEW analytics.v_software_cost_per_employee_company_2025 AS2WITH employee_count AS (3 SELECT COUNT(*)::int AS total_employees_20254 FROM analytics.dim_employee5 WHERE (start_date IS NULL OR start_date <= '2025-12-31'::date)6 AND (end_date IS NULL OR end_date >= '2025-01-01'::date)7),8company_spend AS (9 SELECT SUM(COALESCE(total_spend_2025, 0))::numeric AS total_software_spend_202510 FROM analytics.vendors_2025_clean11)12SELECT13 c.total_software_spend_2025,14 e.total_employees_2025,15 ROUND(c.total_software_spend_2025 / NULLIF(e.total_employees_2025, 0), 2)16 AS software_cost_per_employee_202517FROM company_spend c18CROSS JOIN employee_count e;Architecture
Built like decision infrastructure, not a one-off dashboard.
BudgetDB shows the full operating path from source data to trusted executive reporting.
Analytics layer
Composable Postgres views
CTEs and allocation logic
Department/category rollups
Executive outputs
Trust layer
Source-to-fact reconciliation
Variance checks
Pass/fail QA status
Dashboard readiness
Case study
How BudgetDB moves from messy inputs to executive outputs.
The case study is intentionally structured like a product system: problem, inputs, architecture, validation, output, and impact.
Problem
Operations and budget data often lives across spreadsheets, vendor exports, employee tables, and one-off reporting workflows. The business risk is that leaders make decisions from inconsistent totals, stale calculations, or dashboards without clear QA.
Data sources
Budget workbooks, vendor/software spend, employee and headcount data, department/category mappings, and supporting operational exports. The portfolio version uses anonymized or synthetic data while preserving the structure of the workflow.
Postgres warehouse design
The system is modeled around cleaned dimensions, budget facts, vendor spend, employee/headcount tables, composable views, and executive-facing rollups that can be reused instead of rebuilt for each question.
SQL models and views
Core SQL models calculate software cost per employee, allocate software spend by team, summarize department/category spend, and prepare dashboard-ready outputs for operating reviews.
QA checks
Reconciliation queries compare source totals against modeled fact totals and return variance plus pass/review status before outputs are trusted for executive reporting.
Business impact
BudgetDB demonstrates how product thinking and analytics engineering turn messy operational data into decision infrastructure: faster review cycles, clearer spend ownership, and more trustworthy executive dashboards.
Executive outputs
Dashboards remain the output, not the only proof.
Screenshots support the story, while the primary evidence is the model and QA logic behind the reporting layer.
