Giving a multi-franchise shipping platform an architecture it could grow into

The problem

This was a freight and shipping platform used by several different franchises, each with its own customers, its own pricing, and its own way of doing things. On paper that’s a simple idea: one piece of software, several businesses running on it. In practice it’s the kind of thing that quietly gets more complicated every month, because every franchise wants something slightly different, and every “quick exception” you bolt on makes the next one harder to add cleanly.

Freight and logistics also isn’t forgiving software to get wrong. A shipment that goes to the wrong depot, a booking that silently fails, a price that’s calculated incorrectly: these aren’t cosmetic bugs, they’re money and trust walking out the door. The business needed a platform that could keep adding franchises and customers without every new one meaning a fresh round of bugs and firefighting.

When I came in as lead technical architect, the platform worked, but it was starting to show the strain of growth nobody had planned the foundations for. Some decisions that made sense for one franchise were awkward for the next, and there wasn’t a clear, shared way of thinking about how the system should be shaped as more businesses joined it.

What we did

The first job was strategic, not technical: get clear on what actually varies between franchises and what doesn’t, and design around that distinction deliberately rather than letting it happen by accident. Some things genuinely need to differ, pricing rules, certain workflows, how invoices look. Other things should be identical everywhere, because that’s what keeps the platform maintainable and keeps bugs from multiplying.

From there, I set the technical direction for how the platform should be structured so that adding a new franchise was a configuration exercise, not a rebuild. That meant separating the core booking and shipping logic, which every franchise shares and depends on being rock solid, from the layer of franchise-specific rules sitting on top of it. Get that boundary right, and a new franchise can be onboarded with confidence. Get it wrong, and every new customer risks breaking something for an existing one.

I also worked closely with the engineering team on the standards and decisions that keep an architecture like this coherent over time: how changes get reviewed, how new features get slotted into the right layer of the system, and where the reliability bar has to be non-negotiable because a mistake means a shipment that doesn’t turn up. Strategy only matters if the day-to-day decisions keep pointing the same direction, so a good part of the role was staying close to the team, not writing a plan and walking away.

Where things landed

The platform now takes on new franchises and new customers without each one being a small crisis behind the scenes. Because the boundary between “shared core” and “franchise-specific” is clear, changes for one franchise don’t quietly break things for another, which used to be a genuine worry.

The engineering team also has a shared way of thinking about where new logic belongs, so decisions that used to need a long discussion now have an obvious answer. That’s worth more than it sounds: it’s the difference between a platform that gets harder to work on as it grows and one that stays manageable.

For a business built on trust and reliability, being able to say yes to onboarding another franchise without a knot in your stomach is the real win here.