Build vs Buy in the age of AI.

"Your website is terrible."

A customer told me. Verbatim. And they were right.

Three years ago that would have opened a process: gather requirements, quote platforms, pick an integrator, six months. This time we relaunched thelabstore.cl and in two weeks e-commerce went from 15% to 35% of the sales mix.

I don't tell it as an achievement. I tell it because it forced me to revisit a rule I thought was settled.

The rule we thought was settled

For twenty years, build vs buy was a question about the cost of building. Do I have the team? How long does it take? What does it cost to maintain?

And at a mid-sized retail company the answer was almost always the same: buy. Obviously. You're not a software company.

AI didn't change the answer. It changed which question it was.

If building a functional replacement takes five days — and it did, I replicated an entire SaaS product in five — then the cost of building stopped being the deciding factor. When the deciding variable gets cheap, the bottleneck moves. In our case it moved to adoption: how many people on a lean team can actually operate whatever you've got.

It's no longer "do I build it or buy it?" It's "is my team going to operate this, or is it going to be a license we pay for and nobody opens?"

Five days isn't what it sounds like

One detail that matters, so this story doesn't get read wrong.

Five days wasn't "I built a product." It was "I built the part of that product we used." A mature SaaS carries ten years of edge cases, permissions, integrations and customers who look nothing like me. We needed a fraction.

That fraction is the whole point. Building became viable not because AI writes enterprise-grade software, but because most of a SaaS product's value, for one specific customer, lives in a small slice of its surface. And that slice now takes days.

Today a growing share of our critical software is built in-house: IRIS runs the stores, Cerebro watches pricing, Draper decides what to offer each customer, Meridian measures marketing, Delphine helps buy, Octavius Flow runs the marketplaces, Cifra consolidates cash, Chispeza hires and trains salespeople.

Nine systems. None of them bought.

What we do buy

It would be dishonest to sell this as "we buy nothing."

SAP runs the ERP. BigQuery holds the data. Meridian is built on Google's Meridian, not from scratch — our work was the per-brand pipeline, the eight independent models and the weekly retraining, not the Bayesian engine. The marketplaces Octavius Flow operates on belong to MercadoLibre, Falabella, Paris and Ripley.

The rule we pulled out of it, which I think generalizes:

Buy the infrastructure. Build the decision.

Nobody should write their own database, their own ERP or their own MMM engine. But the logic that decides what price to set, which customer to talk to, which shoe to buy — that logic is the business. Buying it means buying someone else's judgment and hoping it resembles yours.

The maintenance objection

This is where someone always raises a hand, and fairly. A SaaS charges you for not thinking about updates, security, uptime, and the person who left. Nine internal systems are nine things somebody has to maintain, and that cost doesn't show up in launch week.

I expected it to hurt more than it does. And I think the reason is exactly what makes building worth it: they're custom made.

A SaaS carries ten years of surface built for customers who aren't us, and somebody maintains that surface — you pay for it in the license, even if you use 15% of it. Ours does what we need and nothing else. Less surface is less to maintain, and it's also less to understand when something breaks at eleven at night.

It isn't free, and I won't claim it is. But the intuition that nine internal systems are nine times the problem turned out to be wrong, and not because we're fast: it's that none of them carries weight we don't use.

How we decide now

Four questions, in this order.

Is this infrastructure or is it judgment? Infrastructure gets bought; judgment gets built.

Where do the people who'll use it already work? If the answer is a channel the SaaS doesn't support — WhatsApp, in our case — buying means also buying an adoption problem that doesn't appear in the demo.

What fraction of the product do we actually need? If it's 15% of its surface, the price of 100% stopped being a bargain.

Can we measure whether it works? This one disqualifies in both directions. An in-house system that can't prove its effect is as bad as a license nobody can evaluate.

This doesn't make us a software company

And I don't want it to. We're a multi-brand retail group. The software we build exists to run stores better, not to be sold.

What changed is smaller. We stopped accepting "we're not a technology company" as a sufficient reason to buy.

For twenty years it was. Now it has to be justified, case by case.

If you had to defend your last software purchase today, would you defend it for what it does — or for what building it would have cost in 2019?