Use case
Reporting for a public-sector collaboration platform
A UK public-sector collaboration platform needed reporting that its platform supplier's exports could not give. A small team built it by hand. We are using that build as the test case for Moorhold.
Nothing on this page has yet been built or measured on Moorhold. It describes what the original build involved, how Moorhold is designed to handle each part, and how we will know whether it worked. When there are results, they will be published here, with their limits.
What it took by hand
Typical government data work, and hard for the usual reasons
The team built the reporting over several weeks of daily work, as a desktop application written in Python feeding a large Power BI model.
They had no always-on server, so the scheduler was a laptop. That, and nothing in Power BI itself, is what made it a desktop application.
- The source was a general-purpose API with no change feed, short-lived tokens, undocumented calls and a rate limit that disagreed with its documentation.
- History had to be loaded once, then kept up to date, with missed days caught up.
- Failures were silent. A capped export looks like a real decline.
- The output was a large Power BI model, with forecasts, scoring and recommendations.
- Managers had to see only their own workspaces.
How Moorhold does it
Declare the pieces that were hand-built
The claim we are testing: a team can build the same reporting service on a self-hosted open-source stack, without a Microsoft Fabric capacity, with less effort, by declaring the pieces that were hand-built. It does not claim Power BI is unnecessary: many organisations already hold Power BI licences. A team that uses Superset needs no Microsoft licence at all.
| What hurt | How Moorhold handles it | Still custom code |
|---|---|---|
| A laptop was the scheduler, with a lock file and a password on each laptop | Airflow runs the schedule on your server; passwords are references to your vault | None |
| An API with expiring tokens, paging, throttling and a history to load and resume | A declared REST API source, loaded with dlt, that picks up where it stopped | The supplier's quirks, written once as a dlt source |
| Silent truncation, duplicates and a stale baseline | Declared data checks and reconciliation that fail loudly and raise a proposal | The tolerances and the baseline logic |
| A slow refresh stitched together from exported files | Reporting tables (marts) in the database, served to the dashboard tools | The mart models |
| A Power BI model generated by hand | A Power BI project generated from the same definitions as the Superset dashboards | Complex DAX measures |
| Forecasts, scoring and matching running inside a desktop app | Scheduled analytics tasks on the server | The models themselves |
| A list, a flow and a role to limit what each manager sees | One row-level rule, projected into each reporting tool | The query behind the access table |
What is still being proven
The demonstration
In progress
- A mock supplier API that misbehaves the same way as the real one, with invented data only.
- A declared API source, loaded daily and backfilled, with a run killed on purpose that must resume.
- Checks that catch the truncation and the duplicate, and a stale baseline that is reported.
- Reporting tables in Postgres, a Superset dashboard, and a generated Power BI project opened by a person.
- One row-level rule that shows a manager only their own workspace, in both tools.
How we will know it worked
- Someone who did not do the original build gets from a clean server to a working dashboard, and the time is recorded.
- A killed backfill resumes without duplicates, and both checks fire.
- The same measure gives the same number in Superset and in Power BI.
- The supplier-specific code is counted and compared with the original. We will not claim "less effort" without that number.
Limits
What this will not prove
- It does not remove the supplier-specific work. The supplier's quirks are still code.
- Refreshing a Power BI Service report from a self-hosted database still needs Microsoft's on-premises data gateway, which runs only on Windows (Microsoft Learn: install an on-premises data gateway, page updated 10 August 2026, checked 5 October 2026).
- Power BI is licensed separately. Superset is the route with no Microsoft cost.
- Public-sector buyers need more than a technical test: accreditation, hosting location and procurement rules are outside it.
- It is one team's experience. It suggests a direction; it does not establish a general saving.
Have a similar problem?
If your reporting depends on a laptop, a supplier export or a platform you would rather not be tied to, we can help now, with or without Moorhold.