Projects

They came to us with the usual: lots of data, a few reporting tools, a feeling something better was possible. Fabric was new. Nobody had built much real-world on it yet. We took the brief and said yes anyway.

The prototype turned into a working pipeline that put 100+ hours back in the team's calendar every week. After that, the conversation shifted from "can this work" to "how do we run it ourselves". So we ran an eight-month SQL programme alongside the build, and started showing up to C-suite reviews with architecture diagrams instead of dashboards.

The brief was tight. Three months. Production grade. Real source systems. Real security. Needed to work, not look like a demo.

We wired up the pipelines (Dataflow Gen2 where it earned its place, notebooks and Python where it didn't), set up OAuth2 against the source APIs, and built a tiered security model so the right people saw the right rows. Then we sat with the data team and went through everything until they could break and fix it themselves. On time. On budget. Quietly.

They called it Project Phoenix. Phoenixes burn down before they rise, and so it went: years of accumulated data quality issues, duplicate members, stale records. We worked through it with cleansing scripts, deduplication passes, and free government datasets to fill the gaps where we could.

Once the data was something you could trust, we rebuilt cross-departmental reporting in Power BI on top of the new D365 platform and a layer of APIs. Data quality lifted by about 90% by the end.

Adult social care reporting has a particular shape: half of it is for the people doing the work, half is for the regulator looking over their shoulder. Both need to trust the numbers. They don't agree on what "simple" means.

We designed two report suites that shared one data model, automated the pipelines beneath them, and wrote a data strategy the team could actually pick up and use. Along the way we built a small .NET ingestion tool to talk to their LMS API, because nothing in social care comes out of the box.

The previous deck did the job, but it was held together with a lot of repeated DAX and a few brave assumptions. We rebuilt it using calculation groups and dynamic format strings, the boring stuff that turns a fragile report into one that survives changes.

The visuals also needed a quiet redesign: less chart-junk, more breathing room, more confidence in the numbers being shown. The board didn't notice the engineering, which is exactly the point.

They had Power BI reports that worked, mostly, and Azure Data Factory pipelines feeding a CRM migration that didn't. We came in for a few weeks, redid the reports properly, and chased down the pipeline issues until the migration could move again.

The work itself wasn't dramatic. The context was. So we kept our heads down, fixed what was broken, and got out of the way once it was running.

This one ran on a tight clock. The CRM migration had a fixed date. The dashboards were on the critical path. We built the datasets, wrote the data quality checks, and shipped the Power BI reports inside the window. No drama, no extension.

Housing associations have data everywhere. On-prem databases nobody quite remembers setting up. Azure services someone added a few years ago. Dynamics 365 for the customer side. SharePoint for the bits in between. The job was to make all of it talk to one Power BI model, in a way other developers could maintain.

We worked Agile with the wider team, did peer reviews on every report that went out, and quietly introduced modelling and governance practices that reduced redundancy and made the whole thing more responsive.

The audience here was multi-academy trusts looking at attendance, achievements, behaviour, grades, the stuff that makes a school's day. The data sat in Azure, ran into the hundreds of millions of rows, and the Department for Education kept updating the rules on top.

The job was partly authoring new reports in SQL, Power Query and DAX, and partly third-line support when something deep underneath stopped behaving. We also rebuilt a chunk of legacy reports for faster load times, because nothing erodes trust in a dashboard quite like a spinner.

Honeywell launched a SaaS platform that changed how commercial fire systems are commissioned, monitored, and maintained. EMEA had a few hundred engineers who needed to learn it without disrupting live sites.

We wrote 30+ online training modules, a 200+ page PDF manual, and ran sessions for over 100 engineers. Then we did the demo circuit: 60+ channel partners at customer sites, events, and conferences. The product worked. Most of the job was making sure the people using it did too.

Logistics doesn't pause. 700+ hauliers depended on bespoke software that needed to behave at all hours, and the team was the safety net across all three lines of support.

The day job was triage; the deeper work was SQL, queries, views, stored procedures, triggers, agent jobs for bespoke deliverables, and the kind of Crystal Reports that nobody loves but everyone needs.

Document software sits underneath the boring-but-essential bits of a finance team's day: invoices going out, credit chases coming in, scanned paperwork landing somewhere it can be found again. The integrations were with Sage, Dynamics, and SAP. Three systems, three opinions on how the world works.

It was the job that taught us 80% of integration work is reading the documentation carefully, and the other 20% is being patient with vendors.