Case Studies
Real problems,solved in production.
Each study walks through one real engagement: the problem as we found it, how we diagnosed it, and the architecture decisions that fixed it.
How to read these
What is in a study and what is deliberately not
Each one is a single engagement written up in the order it happened, which is rarely the order that makes the work look tidy.
The problem as it was found
Not as it was reported. The two are usually different, and the gap between them is the part worth reading.
What was measured before anything changed
A number with no baseline beside it is a claim, not a result. Where a study gives a figure, the measurement that produced it is described with it.
The approach, including what was rejected
The option that was not taken says more about a system than the one that was, so the reasoning is kept in rather than trimmed for length.
No client names unless they asked for them
The environments are described precisely enough to be useful and never precisely enough to identify anyone who would rather not be identified.
Something here look like your situation? Describe it and get a scope and a price back.
Describe the workHeadless commerce migration: zero downtime, 60% more traffic
A monolithic WordPress store where the storefront shared resources with the backend. We decoupled it into a headless architecture: WordPress kept as the backend, a containerized frontend on Kubernetes behind a CDN, multi-layer caching, and a zero-downtime delivery pipeline.
Site traffic, before vs after
The 3-second timeout that silently corrupted production deployments
An e-commerce API's auto-scaled servers kept joining production empty. The cause: a Lambda with a 3-second timeout, one second short of its real cold-start runtime. Automatic retries turned every near-miss into a duplicate, racing deployment.
A 68% infrastructure cost cut, with zero downtime and a more reliable platform
13 servers and 6 load balancers, half of them dead, running at 0.2-2.6% CPU. We measured first, then migrated to a cloud-native autoscaling architecture with an HA database cluster - cutting cost 68% with zero downtime.
Reclaiming years of cloud storage without risking a single user's data
Four years of orphaned media, intermixed with live user content, made a storage cleanup a data-loss risk. We caught two deletion bugs in review and redesigned the operation to be fully reversible.
Containing the blast radius after a credential leak on a consumer platform
A leaked credential was abused in production. The deeper finding was structural: static keys on disk and one over-privileged identity. We rebuilt the environment around least privilege and short-lived credentials.
Have a problem that looks like one of these?
The first conversation is free and usually enough to tell whether it is worth a deeper look at your environment.