Case Studies
Real problems, real solutions, real results.
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.
Need this kind of work?
Both of these projects are representative of how I approach real engagements: understand the actual problem, design for the failure cases, build it to stay up. If you have a similar challenge, let's talk.