Case studies

Problems where architecture shows up as latency, cost, and trust.

Five engagements across SaaS, enterprise, automotive, government, and commerce. Problems, implementation notes, and previously reported outcomes, with evidence limits noted where known. The LLM routing write-up is an architecture discussion without verified benchmark results.

01Automotive technology

Volvo CQRS Framework

A cloud-agnostic CQRS and event-sourcing foundation for autonomous vehicle management work across a large distributed engineering team.

40%faster development

Client
Infosys / Volvo project
Industry
Automotive technology
Duration
2 years
Stack
.NET Core, CQRS, Event Sourcing, Microservices, Domain-Driven Design

The real problem

The team needed more than services. They needed shared patterns for commands, queries, events, auditability, and cloud integration so 22 developers could move without each squad inventing its own architecture.

What I changed

I helped design and implement a domain-driven CQRS/event-sourcing framework with clear bounded contexts, replayable event history, cloud abstractions, and documentation the team could use day to day.

What improved

  • 40% faster development: shared patterns reduced repeated architecture work across squads.
  • Cloud flexibility: the framework supported Azure, AWS, and GCP deployment paths.
  • Audit-ready history: event sourcing made state changes traceable and replayable.

Why it mattered

At this scale, good architecture reduces coordination cost. The win was not just a cleaner diagram. It was a system teams could extend without losing consistency.

Full write-up

02Software as a Service

Multi-Provider LLM Routing

Architecture notes on provider selection, caching, cost controls, and observability; benchmark outcomes are not documented.

Routingarchitecture and tradeoffs

Client
SaaS platform
Industry
Software as a Service
Stack
Rust, OpenAI, Azure OpenAI, Anthropic, Prometheus, OpenTelemetry

The real problem

The product depended on LLM calls, but provider latency, outages, and cost swings made the experience hard to control. The team needed a system, not scattered API calls.

Design approach

The routing architecture scores providers, enforces budget controls, emits telemetry, and handles fallback behavior. Those mechanisms make model calls easier to inspect; they do not prove performance outcomes.

Design goals

  • Routing and caching: separate provider execution from suitable response reuse.
  • Budget controls: make spending constraints and usage visible.
  • Evidence status: no verified latency, cost-saving or uptime results are published for this architecture.

Why it mattered

LLM cost and latency are product problems, not just infrastructure details. Provider telemetry can inform product and engineering decisions; the resulting impact needs measurement.

Full write-up

03Enterprise

RAG on Azure with pgvector

A retrieval system with citations, evaluation, re-ranking, and dashboards so answer quality could be measured instead of guessed.

85%answer accuracy, up from 40% (+45 percentage points) on 500 questions

Client
Enterprise software
Industry
Enterprise
Duration
4 months
Stack
Azure, PostgreSQL, pgvector, Sentence Transformers, FastAPI, Prometheus, Grafana

The real problem

The prototype could generate answers, but the team needed source citations, freshness controls, and a way to know whether retrieval quality was actually improving.

What I changed

I designed a RAG pipeline around pgvector, metadata filters, re-ranking, offline evaluation, and dashboards for answer quality, latency, and cost.

What improved

  • 85% answer accuracy, up from 40% (+45 percentage points) on a 500-question evaluation set: better chunking, ranking, and evaluation.
  • Citation-ready answers: users could inspect where answers came from.
  • Operational visibility: dashboards made quality and performance easier to manage.

Why it mattered

RAG without evaluation turns into prompt tuning by instinct. The important shift was giving the team a feedback loop they could trust.

Full write-up

04Government

Federal Payment Gateway

A secure payment API where auditability, encryption, integration behavior, and documentation were part of the product.

100%audit pass rate

Client
Federal government, via Fusion Alliance
Industry
Government
Duration
6 months
Stack
ASP.NET WebAPI, SQL Server, OAuth/SAML patterns, audit logging

The real problem

The agency needed a payment gateway that could handle sensitive transactions, integrate with existing systems, and satisfy compliance review without last-minute cleanup.

What I changed

I built a REST WebAPI with secure data handling, authentication and authorization patterns, transaction audit trails, integration documentation, and operational logging.

What improved

  • 100% audit pass rate: no critical findings reported.
  • Millions of transactions processed: high-volume payment path handled securely.
  • Cleaner handoff: documentation supported future maintenance and review.

Why it mattered

In regulated systems, the boring details are the system: logs, encryption, permissions, failure behavior, and documentation all have to be designed on purpose.

Full write-up

Have a system with a similar problem?

Tell me what exists today and what isn’t working. I’ll reply with whether I can help and the smallest useful first step.