The Two-Project Problem

A retail founder once told me his app team and his ERP team hadn’t spoken to each other in four months. Not because of a conflict. Because nobody’s job was to make them.

I remember sitting across from him and almost missing the whole point.

He’d called me in because he wanted to talk about replatforming his storefront. New frontend, new checkout, the works. I had a proposal half-written in my head before he finished his second sentence. That’s the trap in this business. Someone says “we need a new app” and you start estimating instead of asking why.

I caught myself and asked one question instead: “When a customer’s order moves from your storefront to your warehouse system, what happens?”

He didn’t know. Not vaguely. Completely didn’t know. He called in his ops lead, who didn’t know either, and then his app lead, who also didn’t know. Three people in the room, each one responsible for a piece of the business, and not one of them could tell me whether an order placed on the app actually landed correctly in the system that was supposed to fulfill it.

That’s the moment I stopped talking about a storefront redesign.

Two teams, two roadmaps, two definitions of done

Here’s the pattern, and once you see it you’ll notice it everywhere in retail. One team owns the ERP or the warehouse system. Another team owns the app or the storefront. Both teams have sprint boards. Both teams ship on schedule. Both teams can show you a demo that works.

And the customer still feels like they’re dealing with two different companies.

Nobody planned it this way. Nobody sat down and decided to split the business into two disconnected projects. It happens because budgets get approved separately, teams get hired separately, and “done” gets defined separately. The app team’s definition of done is a feature that works in the app. The ERP team’s definition of done is a ticket that’s closed. Neither definition includes the question that actually matters to the person paying for the product: does my order, my loyalty points, my return, follow me correctly from one system to the other?

I’ve now watched this play out in warehouses and I’ve watched it play out in loyalty apps, in industries that have nothing else in common.

We spent close to two years embedded inside a UAE retail and sports group’s SAP EWM operations. Real problems, the unglamorous kind: putaway logic failing on multi-floor bin selection, near-expiry stock not routing to the right storage, manual pick-pack steps that should have been automatic years earlier. None of that was an app problem or a storefront problem. It was the back office quietly falling behind the pace the front end had already set, and nobody owning the gap between the two.

Around the same time, we built a loyalty app for a UK pet retail brand where the problem looked completely different on the surface. Hundreds of stores, a punch-card loyalty scheme, and a customer who could not be recognised the same way twice. Walk into the store, you’re a stranger. Open the app, you’re a different stranger. The fix wasn’t a smarter app. It was building the connective layer so the till and the app finally agreed on who the customer was.

Different tech stacks. Different countries. Same root cause both times: two systems that each worked fine on their own and had never been asked to work together.

The question that would have saved me four weeks

My time in this industry has taught me that the fastest way to waste a client’s money is to answer the question they asked instead of the one they should have asked. Early in my career I pitched a full platform rebuild to a client because that’s what he requested in the first meeting. Four weeks in, I found out his real problem wasn’t the platform. It was two internal teams that had stopped talking after a reorg. I had to go back and tell him the proposal was wrong. Uncomfortable conversation. The right one to have.

So now I ask this before I let anyone talk about a redesign, a migration, or a rebuild:

When something crosses from one of your systems to another, does it happen automatically, or does someone have to notice it’s broken first?

If the answer takes more than a few seconds, or if it takes three people in the room to even attempt an answer, that’s the real project. Not the frontend. Not the backend. The handoff between them.

What to do with this if it’s your business

You don’t need a new platform to start fixing this. You need a name.

Pick the one handoff in your business where a customer’s order, points, return, or history moves from one system to another. Ask whoever’s closest to it what happens when that handoff breaks. If you get a shrug, or three different answers from three different people, you’ve found your actual bottleneck, and it was hiding behind whichever team asked for budget first.

Fund that conversation before you fund either team’s next roadmap. It’s cheaper, and it’s the fix that actually reaches the customer.

If you’re looking at a similar gap in your own stack, a conversation with Brainium’s engineering team costs nothing and might save you the four weeks it took me to learn this the hard way.