FieldOps Analytics OS

FieldOps Analytics OS is a self-initiated build I designed, built, and deployed end to end as the proof piece of my portfolio. It models a two-sided field-service marketplace — buyers, providers, work orders, payments, reviews, and support tickets — generates the dataset from a fixed seed, loads it into SQLite, analyses it through a library of SQL files, and presents the results in a Streamlit dashboard. Everything below describes the working build, which runs entirely on generated demo data.

A field-service marketplace holds its numbers in transaction records, not in answers. Leadership needs to know how much volume the platform is moving, how much revenue it keeps after provider payouts, whether the take rate is holding across months and categories, how concentrated revenue is in a handful of buyer accounts, and which buyers are drifting late on payment. Reading that out of raw work-order and payment tables means writing the query again every time someone asks.

A repeatable pipeline instead of ad-hoc queries: generate the marketplace dataset with a fixed seed, load it into a relational SQLite database, and keep the analysis in a versioned SQL library rather than scattered across notebooks. The dashboard sits on top of that layer — sidebar filters, KPI cards, Plotly charts, a finance deep dive, a metric glossary, and CSV export of whatever the current filters select.

• Revenue quality is visible month by month: what the platform keeps after payouts, and whether the take rate is holding.
• Buyer concentration is measured, so dependence on a few accounts surfaces before it becomes an exposure.
• Late-payment risk arrives as a ranked shortlist instead of a collections hunt through payment records.
• Recurring finance questions get answered from a versioned SQL library rather than a fresh one-off query each time.

• A seeded synthetic data generator for a two-sided marketplace: buyers, providers, work orders, payments, reviews, and support tickets.
• The Python-to-SQLite load step that turns those tables into a relational analytics database, plus a bootstrap that rebuilds it on deploy when the database file is absent.
• A library of 13 SQL analysis files covering revenue KPIs, work-order health, provider and category performance, location revenue, payment delay, take-rate trend, and buyer concentration.
• The Streamlit dashboard: sidebar filters, KPI cards, Plotly charts, interactive tables, a finance deep dive, a metric glossary, and CSV export of the filtered dataset.
• The written layer around it — an MIT-licensed repository with a case study, data model, SQL guide, and business-insight write-ups.

• Metric definitions belong in one place. Take rate and success rate can each be computed two defensible ways, and two different answers to the same question is what a stakeholder remembers.
• A fixed random seed is what makes a synthetic dataset defensible — the figures quoted in the documentation have to still be there when someone reruns the pipeline.
• Empty and edge states are the real dashboard work; a filtered view is judged on the selection that returns almost nothing.
• Writing for a business reader forces plain-language labels — a metric glossary is not decoration.

• Automated tests over the pipeline and the metric calculations — the repository has none today.
• A CI check that runs those tests and the SQL library on every push.
• A scheduled pipeline run so the analytics database refreshes on a cadence instead of on a manual rebuild.
• Swapping the synthetic generator for a real data source behind the same SQL layer.