The Build-vs-Buy Question Almost Nobody Asks

"If it isn't easier than doing it in-house, we'll just do it ourselves."

That was a retail ops leader, reading my own proposal in the meeting last year, right there in front of me. Said calmly, which somehow made it land harder. And it's fair. They weren't turning me down, they were telling me the bar. I've heard a version of the same sentence from three different buyers since, including that one. And to be honest... I've said it myself in a prior life.

Build vs. buy usually gets argued on two axes: can we do this ourselves, and what does each version cost. Both have answers. Both are sitting in a spreadsheet by Thursday, which is exactly why teams reach for them first.

But the first one is rarely a real question. Nearly every large company I talk to knows what to do, and even knows how to do it. What they don't have is a person to actually take it on. So the honest version isn't "can we", it's "will we actually staff this properly". And a program can clear both of the original gates and still be the wrong call. Here's why:

Where the learning ends up

Staffing is a near-term problem, and near-term problems get solved. Hire a head or sign a vendor: either way the units move next month. What doesn't get solved in a quarter however - and what actually separates the two paths, is where the learning ends up. Whoever runs the flow day to day is the one who finds out which grade disputes keep coming back, which channel pays for what and when, and which step quietly eats the margin nobody budgeted for losing. None of that usually shows up in the statement of work. None of it shows up in the quarterly review deck. It accumulates in whoever is touching the units.

Outsource the operation instead, and now you're renting capability while your partner keeps the learning. Which is fine, right up until the day you want to change a routing rule and nobody on your side can tell you what it should be. Build it in-house and you keep the learning. You also pay for the slowest and most expensive version of the capability, while your team climbs a curve somebody else already climbed (twice, usually, because the first climb is the one nobody documents).

So it comes down to which of the two you can least afford to not own. Obviously that answer moves depending on how core recovery is to your P&L. And candidly, most teams never get to that question. Short term, the financials look fine. Long term, whoever made the decision has moved on to another role... or another company.

Buy it twice, keep the scoreboard

There's a third option almost nobody prices out, and it isn't the middle of the other two. It's also simpler than it sounds: you buy the capability twice, and you keep the scoreboard. By scoreboard I mean a second number, one that gets generated on your side and that neither vendor can hand you. And before you tell me you don't have the volume for two vendors: you don't need two vendors, just one comparison point could be enough. I'll come back to that.

When I ran Samsung's mobility trade-in program (the world's first OEM-led one, about eighteen months ahead of Apple's), I never had just one vendor for anything that mattered. Processing ran through two vendors in two different locations. Monetization ran the same way: a primary auction channel, plus a challenger allowed to make us an offer on the same units before they ever hit the auction. Champion and challenger, on both halves of the flow.

I've written before about how a champion and a challenger drift apart over eighteen months, and how the volume moves when they do. That was a story about managing vendors. This is the other thing the model does.

Take the monetization side specifically, because that's where it shows up cleanest. The challenger could make us a pre-sell offer on a lot before it ever reached the auction. Somewhere between 30 and 50 percent of the time, that offer netted better than our main monetization channel did. Not on the whole book, just on specific lots, and never predictably, which is exactly why it was worth running.

This isn't to say the champion didn't do a great job; indeed, it was objectively very good - arguably even the best in the industry. The point is we only knew it was good because somebody else was bidding.

Now, a challenger who wins too often stops being a challenger and becomes your new champion. At which point you're back to one vendor and a number you can't check. There's also always the risk that vendors start playing games to see how far they can take the price.

So we'd play games too. We did something that looks irrational written down: we sometimes routed lots to the primary channel that the challenger would have netted more on. On purpose. Not many, and not often (you can only afford so much tuition), but enough that neither side could ever model us and coast. Keeping them both hungry cost us a little money in any given month - but it also gave us a deep and durable understanding of market dynamics.

This learning is also the whole reason this is a true third option rather than just another procurement tactic. The delta between what the champion pays and what the challenger could pay is a number that exists nowhere in the world except on your side of the wall. Neither vendor can hand it to you: one of them doesn't know it, and the other has no reason to.

Your team builds it lot by lot. Which grades the challenger wants, and which ones it quietly avoids. Which weeks the auction runs hot. Which SKU somebody is always overpaying for. Outsource to a single partner and you don't lose that knowledge, you just never generate it, because there was never a second number to hold the first one up against.

You need one comparison point, not two vendors

So, back to the volume question. Not everybody can afford two vendors at once, true. But you can also build it on the cheap. A simple test lot to a second buyer once a quarter does most of the work. So does an RFP you run for real, on real units, even when the incumbent is likely to keep the business.

One caution there, and it does happen: a challenger who wants in will sometimes quote a number they have no intention of honoring. Pick who you invite, which is a lot easier when you know the space, and make it explicit up front that the bid is the price they'll be held to if they win it. What kills the learning isn't the single vendor; it's the single number.

I've watched the other version of this too, from the outside, advising programs that subcontracted a piece of their flow and then went quiet on it for a couple of years. They got the capability, and it worked, and the invoices were fine. What they didn't get was any idea whether the terms were still good, because there was nothing to hold them up against. By the time somebody thought to ask, nobody internally could even frame the question properly. That's the real cost of outsourcing the learning, and it rarely shows up as a line item.

What good looks like

Here's what good looks like: You can name, off the top of your head, the two or three places where your recovery number actually moves. And you know what somebody else would pay for those units this month. Not a range and not a feel: a number, from a second party, on real inventory. When your vendor comes in to renegotiate, you're not reading their deck, you're checking their math - and you can call them out on it when needed.

So when a buyer tells me it has to be easier than doing it in-house, they're right. They're also describing a floor rather than a ceiling. Easier is table stakes. The version worth paying for is the one where you come out the other side knowing more about your own program than you did going in, which sounds backwards and is basically the whole game. Build or buy was never really the question. The question is who's holding the scoreboard when the contract comes up for renewal.