Case studies

Problem

When the vendor MES front end became unavailable, the floor still needed current machine state, job details, and access to production history.

Architecture

A Node and Express application reading MES data from SQL Server, with shared server-side caching so a floor of displays produces one database query per refresh cycle.

Hard part

Several undocumented MES values contradicted their labels. The core work was proving their units and grain, then identifying safe, supported write paths.

Result

A reliable floor-wide production view with audited scrap and downtime corrections through the vendor's supported procedures.

Read the case study→: Mattec Live Production Dashboard

Problem

Each new source required a bespoke pipeline, increasing onboarding time and leaving every implementation to evolve differently.

Architecture

Configuration-driven Python and Spark ingestion into Delta Lake across bronze, silver and gold layers on ADLS Gen2, delivered through Git and Azure DevOps.

Hard part

Designing one ingestion path flexible enough for MES, ERP, SQL Server, API, and IoT sources without accumulating special cases.

Result

New sources are onboarded through configuration, and critical ingestion that once took hours completes in under a minute.

Read the case study→: Metadata-Driven Databricks Data Platform

Problem

SharePoint processes needed current ERP vendors, tooling, buyers, and requisitioners without re-keying data or maintaining a second source of truth.

Architecture

A .NET 8 console application that runs and exits under Task Scheduler, reading Db2 for i over ODBC and reconciling against SharePoint Online through Microsoft Graph.

Hard part

Making reconciliation safe when the source misbehaves: an empty or failed query must never become a delete-everything instruction.

Result

Reference data stays current without re-keying, and a new dataset is a configuration block plus a query file.

Read the case study→: ERP-to-Microsoft 365 Integration

Problem

Maintenance, safety, and HR teams relied on specific operational layouts that no combination of native visuals and DAX could reproduce.

Architecture

TypeScript visuals built on the Power BI Visuals SDK, packaged, versioned and deployed into the tenant.

Hard part

Making each custom visual behave like a first-class one, with real sorting and resizing, sensible defaults, and practical formatting controls.

Result

Four visuals in use in production reports, maintained as report requirements change.

Read the case study→: Custom Power BI Visuals

Problem

Production automation was scattered across scripts whose behavior, prerequisites, and deployment locations were known only to their authors.

Architecture

A single repository of PowerShell and AutoHotkey automation, with every script documenting its purpose, prerequisites, configuration, and deployment target.

Hard part

Turning a collection of useful scripts into an operational system another engineer could understand, verify, and support.

Result

Production automation with clear ownership, repeatable deployment, and enough documentation for another engineer to take over.

Read the case study→: Operations Automation Library