About
Architecting AI that survives contact with production.
I am a .NET specialist with more than 10+ years of production C# behind it — the kind of depth that comes from owning systems end to end, not from reading about them.
More than a decade of production C# — from ASP.NET Web Forms to cloud-native services running on Kubernetes. Somewhere along that sequence the throughline stopped being a language and became a preference: get the shape right while it is still cheap, make the system survive contact with reality, and leave the team able to ship without you.
Most of my work sits in the layer people skip. An AI model is interesting for an afternoon; what decides whether it becomes a product is everything around it — the services underneath, the event flow between them, and the engineering that keeps the whole thing predictable when something upstream fails.
The scope has run from enterprise modules to a startup platform I owned from sketch to product, and on to cloud-native systems where correctness under load was not optional. The domain changes. The shape of the problem does not: get the boundaries right, make failure survivable, and do not make the next person’s life harder than it has to be.
Four positions I hold, and hold to.
Decisions get cheaper early
The data model, the boundaries, the contract. These are the three things worth an extra week, because every one of them multiplies against everything that follows.
Assume the network will fail
If a system only works when everything is reachable, it works in a slide deck. Designing for disconnection first tends to make the connected case trivial rather than the reverse.
Make the safe path the fast path
A delivery process that is pleasant to use gets used. A discipline that requires discipline stops being followed the first week somebody is on fire.
Leave the team able to ship
The measure of the work is not what I designed. It is whether the people who inherited it can change it safely without asking me first.
Where the judgement actually lives.
.NET Architecture
A decade of C# means the framework is not the interesting part — the decisions are. Getting service boundaries, dependency direction and data ownership right while they are still cheap to change.
Cloud Platforms
The unglamorous layer between a codebase and something that runs reliably at three in the morning without a human involved.
Data & Integration
How state moves through a system, and what happens when it never arrives. Event backbones, idempotency, and the failure paths nobody demos.
Applied AI
Shipping models as products: the serving layer, the fallbacks, and the engineering that decides whether a model is usable by anyone but its author. The modelling is the part everyone discusses; the platform is the part that decides whether it works.
Technical Leadership
Owning the architecture and the delivery. Architecture that only one person understands is a liability, not an asset.