I run the operation, and I analyse it,
so I know which problems are worth solving.

Problem Store operations were scattered across paper and spreadsheets, and any real performance or stock insight meant waiting on head-office and stock-team reports, too slow to act on day to day.

Approach Agreed the remit and data access with my regional manager, then gathered requirements from my own analysis and from what the team flagged as slow or manual. Built and iterated Storely with them through repeated rounds of user testing. Under the hood: React and Supabase, CSV ETL from Retail Advantage, Holt's demand forecasting, ABC stock classification, and per-person row-level security.

Impact £405k+ turnover since opening; 1,201 products under weekly forecast; and waste, refunds, banking and rota on one auditable trail a team of 5 uses every shift, insight the store no longer waits on head office for.

Problem A transaction-monitoring team has to answer two questions at once: which payments are worth a human’s attention, and whether every number they report can be trusted. I set out to reproduce that workflow end to end, from raw payments to tested, reportable datasets.

Approach Raw data in BigQuery, transformed and tested with dbt into a star schema, scored for fraud risk, evaluated against real labels, surfaced in Looker Studio. Three dbt test types enforce integrity so any figure traces back to source.

Impact 117,103 transactions modelled, with the alert threshold treated as a business decision rather than a fixed default: around 83% recall when the aim is to catch as much as possible at first-line review, against 99.4% precision when it is tuned to auto-action a case. Two different risk appetites, two different settings.

Scope Synthetic PaySim data; fraud prevalence is inflated by design and scoring is rule-based, chosen for interpretability over real-world detection rates.

Problem Most "learn SQL" tools have one of two flaws: they grade by matching your text, so a correct query written a different way gets marked wrong, or they never let you run a real query at all. Neither actually teaches the skill an analyst needs.

Approach I specified the whole product up front in a six-document set, product requirements, software requirements and architecture, then built to it: a genuine SQLite engine running in the browser via WebAssembly, with answers graded by comparing result sets rather than text. Every reference query is engine-verified before it ships.

Impact 7 worlds · 118 lessons · 181 hand-checked exercises, free, no signup to try. A finished product that proves both the SQL depth an analyst role needs and the discipline to specify something properly before a line of it is built.