How I cut a 500-report estate in half — and built the tooling to make sure it never bloated again.
The analytics team was sitting on an estate of around 500 reports — a years-long accumulation of work that had never been systematically reviewed. Some had no active users. Some were near-duplicates with different names. Some measured the same KPIs under different titles, sent to overlapping audiences on overlapping schedules.
For analysts, it meant maintaining reports nobody read. For managers, it meant navigating a cluttered landscape with no clear picture of what existed, who owned it, or whether it was still needed. There was no single place to see the full picture — and no process to keep it clean.
The problem wasn't just the reports. It was that there was no system to manage their lifecycle — creation, ownership, or retirement.
My manager spotted this as a problem worth solving. I was asked to take it on — and given space to define what the solution looked like.
I started by doing the audit myself — pulling usage data and talking to people across the team to understand what was actually being used, what was duplicated, and what could safely go. That investigation surfaced the 53% figure: more than half the estate was obsolete.
Then I proposed a solution with wireframes. Not just a decommissioning exercise — but a suite of two tools to make the entire reporting lifecycle visible and manageable going forward. The team had been thinking about Microsoft PowerApps. I introduced Flask, and made the case for building it properly.
Analysed usage data and interviewed the team to identify unused, duplicate, and redundant reports
Designed both portals in Powerpoint — showing how they'd look, how they'd function, and how they'd connect
Developed the suite in Flask — a deliberate choice over PowerApps that introduced the team to a more scalable approach
Retired 250+ obsolete reports. Estate reduced from ~500 to under 250.
The suite consisted of two tools, used by both analysts and managers — giving everyone a shared view of the reporting estate for the first time.
A centralised registry of every report in the estate. For each report: what it covers, who owns it, how long it's been running, and which KPIs it tracks. Analysts and managers could finally see the full picture — and make informed decisions about what to keep, consolidate, or retire.
A tool for report creators to schedule automated sends — weekly, monthly, or at any defined frequency — without manual intervention each cycle. Replaced an ad-hoc, request-based process with something repeatable and self-managed.
The team was planning to build this in Microsoft PowerApps. I proposed Flask instead — more flexible, more scalable, and a meaningful capability upgrade for the team. They hadn't used it before. Getting buy-in meant showing it in wireframes first, then delivering the proof in the build.
Before writing a line of code, I designed both portals in Powerpoint — laying out how they'd function and how users would move through them. This got the team aligned on what we were building before any technical work began.
The immediate result was a cleaner estate — less clutter for analysts maintaining reports, less confusion for managers and users navigating them. But the more durable impact was the system: for the first time, the team had tooling to manage their reporting lifecycle proactively, not reactively.
The team hadn't considered Flask before. Delivering something they could see — first in Powerpoint, then in working code — is what made the case.