Case Studies
Real problems, real constraints, real numbers.
Bulk Dataverse Import Pipeline
Problem
A government client needed to migrate large datasets — 20,000-row Excel files — into Microsoft Dataverse. The manual process required staff to enter records one by one, taking weeks per file. Errors were common, there was no audit trail, and the volume was only growing.
Solution
Built an Azure Function deployed to Azure Government that handles the entire pipeline: Excel parsing, parent record lookups against existing Dataverse data, and batched inserts using the Dataverse Web API's $batch endpoint at 1,000 operations per request. Authentication uses System-Assigned Managed Identity — no credentials stored in code or configuration. Failed rows are logged back to a SharePoint list with full error details, giving the client a per-row audit trail and a clear queue for any records that need manual review.
Result
A process that had required weeks of manual data entry became a fully automated, repeatable pipeline. 40,000 individual API calls were reduced to roughly 40 batched requests. The client now imports new data files in minutes, with a complete audit log and zero manual intervention for the happy path.
DelveMUD AI Integration Layer
Problem
Building AI-powered game features — NPC conversation, procedural dungeon generation, quest creation, item crafting and appraisal — with a naive single-provider integration creates hard dependencies: one vendor outage or rate limit cascade takes down all AI functionality at once. Model upgrades require touching game logic. There's no isolation between subsystems.
Solution
Designed and built a multi-provider LLM abstraction layer where each AI subsystem (NPC agent, dungeon director, quest generator, item appraiser) is implemented as an independent module behind a common provider interface. Each subsystem has its own rate limiting, response caching, and fallback chain — so a rate limit on the NPC agent doesn't affect dungeon generation, and a model provider going down triggers an automatic fallback rather than an error. Providers are registered by name; swapping the model behind any subsystem is a configuration change, not a code change.
Result
Models are hot-swappable with zero game-side code changes. Subsystem failures are isolated. The architecture absorbs provider outages and rate limits without cascading. The pattern is directly applicable to enterprise production systems: any application that needs resilient, observable, multi-provider AI features without vendor lock-in.
Deployment Pipeline: 4 Hours to 15 Minutes
Problem
A mission-critical government platform with hundreds of daily users was deployed mostly by hand. A release took about four hours of manual steps, and every manual step was a chance for a mistake. The team shipped less often than it should have because deploys were something to dread.
Solution
Engineered and fully automated the CI/CD pipeline in Azure DevOps, with PowerShell doing the work people used to do by hand. Builds are reproducible and the pipeline runs the same way every time, inside the approval process the environment requires.
Result
Deploys went from roughly four hours to 15 minutes, a 94% reduction, and the manual-error steps went away with them. Releasing became a normal part of the week instead of an event.
Document Template Automation
Problem
A large set of Word document templates needed the same edits applied to every one of them. The default plan was to open each file and do it by hand, which is about a week of somebody’s time, and hand edits across that many files guarantee a few come out wrong.
Solution
Wrote a PowerShell tool that drives Word through its automation API: open each template, apply the edits from one definition, save, move on. Built it on my own initiative because the manual plan was obviously the wrong one.
Result
About 40 hours of manual work replaced by one run, with no copy-paste mistakes. This is the kind of small program I build under Custom Tools & Automation.
Need this kind of work?
These four are how I approach every engagement, big or small: understand the actual problem, design for the ways it can break, build it to stay up. If you have something similar, let’s talk.