Boozt.com

What was Boozt, and what did I walk into?

Boozt is one of the larger fashion retailers in the Nordics. It runs two storefronts — Boozt.com and Booztlet.com — off the same underlying data, which is an elegant idea right up until the two of them start disagreeing about what a product costs or whether it's in stock.

I joined as one backend engineer in a large in-house team, on a codebase years older than my time there, written by people who had very good reasons for the decisions they made. None of those reasons were written down anywhere, which is normal.

So this isn't a story about building a company's platform. It's about owning two pieces of one that already existed, and not breaking the rest.

What was actually going wrong?

Two things, and they were different kinds of problem.

The first was shipping. Prices were effectively fixed, which meant the company was losing money on some orders and overcharging on others, and nobody could change it without touching a dozen places at once.

The second was the sync between the two stores. It ran as background jobs on a schedule, which is fine at small volume and quietly terrible at large volume. Data drifted. A customer could see one thing on one site and something different on the other, and support would get the call.

What did I build?

A dynamic shipping engine. Rates that respond to what's actually in the cart and which carrier is being used. It sounds like a pricing feature, and that's how it was described to me, but it isn't — it runs from the checkout screen the customer sees all the way through to how the warehouse packs and routes the order. Getting it wrong doesn't produce a bug report, it produces a wrong parcel.

And I replaced the batch synchronisation between the two storefronts with an event-driven architecture. Instead of asking "what changed since last time?" every few minutes, the system now says "this changed" the moment it happens. The two stores stopped drifting.

Alongside that, the ordinary work: new API endpoints, and cutting response times on existing ones — measured under real traffic, not in a benchmark on my laptop.

What was the hard part?

Not the code. The hard part of this kind of job is restraint.

When you land in a large codebase that isn't yours, every instinct tells you to rewrite the parts you don't like. That instinct is almost always wrong. The conventions are there because somebody hit a problem you haven't hit yet, and the fastest way to become useless to a team is to spend three months making the code look the way you'd have written it.

So I wrote Symfony the way they wrote Symfony, used their test setup, followed their standards, and spent the first weeks reading more than typing.

Why does this one matter?

Because greenfield is the exception. Most companies that need help already have something running, with customers on it and revenue flowing through it, and the question they're really asking is: can I let this person near it?

This is the case that answers that.