Tarnwick
Composable Commerce Platform
The Situation
Tarnwick was losing the speed game. Their monolithic e-commerce platform — built five years ago when they had 200 SKUs — now supported 12,000 products across three brands.
Every change required a full deployment. Every deployment required a prayer. The frontend team waited on the backend team. The backend team waited on the database team. Everyone waited on Friday.
Their competitors were shipping daily. Tarnwick was shipping monthly, on a good month.
When my growing retail platform is constrained by its own architecture,
I want to let independent teams ship changes without coordination overhead,
So I can compete on speed-to-market while keeping the system reliable.
The Approach
The temptation was to do a big-bang rewrite. Start fresh, modern stack, clean architecture. I've seen that movie — it doesn't end well. Instead, I designed a strangler fig migration: wrap the monolith, extract services incrementally, and never stop shipping.
The first step was identifying the seams. Where did the monolith's modules actually talk to each other? I mapped every internal dependency and found that the system was coupled in three places: the product catalog, the checkout flow, and the CMS layer. Everything else was already loosely coupled — it just didn't know it.
We started with the storefront. The existing server-rendered pages became a thin Next.js application that pulled from a new headless CMS (Sanity) and a product API that still talked to the old database. From the customer's perspective, nothing changed. From the team's perspective, everything changed — the frontend team could now deploy independently, multiple times per day.
The checkout flow came next. We extracted it into its own service with its own database, communicating with the rest of the system through events. This was the hardest part — not technically, but organizationally. The checkout team had to learn to own their service end-to-end.
The System
The final architecture was deliberately simple:
No Kubernetes. No service mesh. No distributed tracing platform. Just well-defined boundaries and teams that owned them.
The Outcome
The conversion lift was the surprise. We hadn't optimized for conversion — we'd optimized for speed. But faster pages, combined with the ability to A/B test landing pages independently, compounded into a 16% lift over six months.
OUTCOMES
CAPABILITIES APPLIED
Let's talk about what you're building.