Recent Engagements
We don't take many clients on at once, and we don't write up the work that didn't go well, but the patterns repeat. Tangled analytics, platforms that outgrew themselves, teams stuck firefighting. Below: two client engagements written up in full, then six representative scenarios for the engagement types we haven't written up yet.
They'd inherited what most teams inherit — duplicated definitions, brittle pipelines, a backlog growing faster than the team. We didn't pitch a moonshot. We helped them rebuild the architecture so the numbers were consistent and the work was shippable. Boring outcomes, but the right ones.
The client is a fast-growing HR SaaS company headquartered in Europe. By the time they engaged us, their analytics function had been running for several years and had accumulated the typical signs of organic growth: the same business entity defined inconsistently across multiple tables, fragile pipelines that broke under reasonable load, and a single point of knowledge concentrated in two long-tenured engineers. New report requests took up to a month to deliver.
We embedded two senior engineers with their team for six months. The first six weeks were spent on discovery — mapping the existing architecture, cataloguing data definitions across the business, and identifying the highest-leverage points for intervention. We then proposed a three-phase remediation plan, prioritised by business impact rather than technical interest.
Their data volumes had quietly outgrown a platform that was never meant to carry them. We built a new one from scratch, designed around how the business actually runs — and handed it over so their team could run with it themselves.
The client is a US-based real estate analytics company that had grown rapidly in customer base and the volume of property data they processed. Their original setup — a small set of scripts feeding a single database — had served them well in the first two years but was now the limiting factor on both reliability and product velocity. Adding a new data source took weeks. Recovery from a failed run was manual.
We delivered a complete data platform across five months, designed end-to-end around their specific business model. The architecture was deliberately conservative: well-understood components, conventional patterns, generous documentation. We wanted the team to be able to operate, extend, and reason about the system without us.
An internal audit asked a question the platform couldn't answer: where did this number come from? We rebuilt the reporting layer so every figure carries its own history, and a three-week reporting scramble turned into four days.
With DORA enforceable since January 2025, an internal audit flagged that the bank's lending-analytics team could not reproduce a historical risk figure on demand. The number lived across six undocumented ETL jobs, and nobody could say with confidence which version of the transformation logic had produced last quarter's report. Ownership of the underlying data was fuzzy too; risk, finance, and compliance each held a piece. Quarterly regulatory reporting took roughly three weeks of manual reconciliation before it could be filed.
We ran a structured architecture review first, then rebuilt the core reporting layer on a Data Vault pattern: every record carries its source and load time, and history sits in satellites, so "what did this figure look like last quarter" became a query instead of an investigation. We assigned named ownership per domain and automated the lineage tracking, so the audit trail no longer needs an engineer in the loop.
Our client here was another consultancy. They'd won the project and lacked the bench; we supplied one engineer under their brand and stayed invisible to their end client.
A boutique Snowflake-certified consultancy had just won a mid-market retail client's migration project, but two of their own senior engineers were already committed to another engagement for the next quarter. Turning down the work meant losing the client relationship; taking it on without the right bench risked missing the agreed go-live date.
We supplied one senior Snowflake and dbt engineer white-label, working entirely inside the consultancy's own delivery process, tooling, and client-facing branding. From the end client's side, the engineer was indistinguishable from an in-house hire. The consultancy kept the relationship and the margin.
Operations knew what the lines were doing. Planning found out a day later, from a spreadsheet. We put both on the same numbers, refreshed in minutes.
Sensor and telemetry data from four production lines sat in a historian system nobody outside operations could query. Finance and planning relied on manually exported spreadsheets refreshed once a week. When a line stopped, that fact wasn't visible in planning systems for up to 24 hours. Leadership wanted real-time OT and IT visibility ahead of piloting Fabric IQ, but had no unified data layer to build it on.
We built ingestion from the OT historian and the SAP ERP into Microsoft Fabric, then a real-time layer on top that joins telemetry with production and planning data. Line stoppages now raise an alert within minutes instead of surfacing in next week's export, and plant managers and finance read dashboards built from the same model, so the numbers agree.
Microsoft stopped selling their capacity tier. Finance was bracing for the worst-case renewal. We sized the move on evidence first, then migrated one business unit at a time.
The firm was on a Power BI Premium P-SKU that Microsoft had stopped selling, so any renewal would force a move to Fabric F-SKU capacity. Nobody had modelled which tier they actually needed, and finance was bracing for a worst-case cost jump. Roughly 40 reports across three business units depended on the existing capacity, and some were already showing interactive query delays.
We ran our fixed-fee capacity-sizing assessment first, profiling the workload behind all 40 reports, and delivered a written report recommending a specific F-SKU tier with cost modelling attached. Only after the client approved the plan did we run the migration itself, in three phases by business unit, so no report went dark mid-cutover.
The engineer who understood the Azure environment left right after the deal closed, and the bill kept growing anyway. We found where the money was going and shut off what nobody was using.
Shortly after acquisition, the engineer who understood the company's Azure environment left. Monthly cloud spend had grown 60% year over year with no corresponding growth in usage that anyone could explain. The PE fund's operating partner needed a defensible number and a plan for the next portfolio review, not a guess.
We ran our fixed-fee, 4-week audit covering architecture, reliability, cost, velocity, and team coverage, and identified orphaned resources, oversized reserved capacity, and two pipelines silently running the same transformation twice. We delivered a prioritised remediation plan with effort estimates, then executed the top-priority items ourselves over the following three months.
The agency won the panel; the first requisition was an Azure Data Engineer their bench couldn't cover. We supplied one pre-vetted candidate inside the SLA window, and the panel slot held.
The agency had just won a spot on a mid-market retailer's Vendor Management System panel, and the retailer immediately opened a requisition for an Azure Data Engineer. The agency's own bench was infrastructure and ERP generalists, with no deep Azure data vetting capability. Missing the SLA on this first requisition risked the entire panel relationship before it had properly started.
We supplied one pre-vetted Azure data engineer under a disclosed subvendor arrangement the agency was comfortable sharing with its own client. The candidate had already been through our standard technical assessment, video interview, reference checks, and ID verification before submission. The agency kept the client relationship, the contract, and the margin.
More to Come