Build vs buy a retail decision platform: an honest framework

Most retailers reach the build-vs-buy question from a position of apparent strength. You already have a data warehouse, a few years of clean transactional history, and a data-science team that has shipped forecasting models that work. Adding a decision layer on top looks like an incremental step — a quarter of engineering, maybe two. So the reflex is to build it in-house, and on the surface that reflex is rational. This article doesn't argue against it; it gives you the framework to know whether the reflex holds once you leave the POC and enter production.

What the in-house POC proves (and what it hides)

The in-house proof of concept is cheap, fast, and almost always convincing. Your team pulls a season of sales and stock from the warehouse and trains a model on one category. A few hundred lines turn the forecast into a markdown or replenishment recommendation. Three weeks later you have a notebook that produces plausible decisions on real data. It demos beautifully in a steering committee.

What the POC proves is narrow but real: your data is good enough, and the modeling is not the hard part. That conclusion is correct. But decide the rest is "just engineering" and you'll repeat the most common failure in retail data projects — the three classic mistakes that kill them.

Because the POC runs in conditions that have nothing to do with production. One category, not forty. One season, run once, not a continuous flow recalculated every day. A data scientist hand-cleaning the input, not an automated pipeline tolerant to a WMS feed that arrives late or malformed. The recommendations land in a spreadsheet a human reads, not in the ERP a store manager acts on by Tuesday morning.

The POC answers "can we compute a good decision?" Production has to answer a harder one. Can we compute the right decision on every SKU/store pair, every day, propagate it to the systems that execute it, and learn from what happened? Those are different questions, and the gap between them is where build-it-yourself projects stall.

The three places build-it-yourself stalls

When in-house decision-layer builds get stuck, it is rarely the model. It is one — usually all three — of the following.

1. Continuous integration to operational systems

The POC reads from the warehouse and writes to a file. Production has to read from and write to the live operational stack: ERP, WMS, the pricing engine, the e-commerce platform, the planning tool. Each of those is a bidirectional integration that has to run every day, survive partial failures, and reconcile data that disagrees between systems.

This is not data-science work. It is systems engineering, and it is the part nobody scopes during the POC. A markdown decision that can't write back into the pricing engine stays a spreadsheet — the dead end that turns retail data useless without a decision layer.

Teams routinely underestimate this by a factor of three or four. The integrations get pushed quarter after quarter, manual exports fill the gap, and the "few weeks of engineering" quietly becomes a roadmap of its own.

2. Maintaining the business-rule layer as it evolves

Every retail decision sits on top of business rules: minimum facings, supplier pack sizes, never-out-of-stock lists, end-of-life markdown floors, store-cluster constraints, exclusivity windows. In the POC, you hard-code the handful that matter for one category. In production, there are hundreds, they differ by category and country, and they change constantly — every season, every buyer reorganization, every new supplier contract.

A hard-coded rule set is a snapshot that is wrong within a season. Building a maintainable rule layer — one where a category manager can change a constraint without a code deploy — is a real product to design, not a config file. We unpack why this matters in why 80% of retail business rules are misused in data systems.

Underestimate this and you get the classic failure: the model produces recommendations operations reject, because the rules in the engine no longer match the rules in their heads. Adoption collapses, and the build looks like a model problem when it is a maintenance problem.

3. Closing the execution-and-learning loop

The POC produces a decision. It does not observe whether the decision was executed, whether it worked, and feed that back into the next cycle. Closing that loop — decision, execution, outcome, learning — is the part that separates a recommendation engine from a decision platform.

Building it means capturing execution feedback from operational systems, attributing outcomes, and feeding them back without a human stitching spreadsheets together. It is the hardest of the three to build and the easiest to defer, which is why most in-house systems plateau as one-directional recommenders that never improve.

When building genuinely makes sense

Buying is not always the answer, and pretending otherwise would be dishonest. There are real conditions under which building the decision layer in-house is the right call.

Build when decisioning is your core competitive differentiation. The test: is it your pricing or allocation logic that wins you the market — not your product, not your stores, but the decision engine itself? If so, owning it end-to-end is strategic. You don't outsource your edge.

Build when you can fund a permanent product team, not a project team. A decision platform is not a project that ships and ends. It is a product that needs continuous engineering: new integrations, rule-layer evolution, loop maintenance. If you can staff and retain a dedicated team for years — platform engineers, not borrowed data scientists — building is viable.

Build when your operational stack is genuinely unusual. If your systems are so proprietary or so far from market standards that no platform integrates cleanly, the integration advantage of buying shrinks, and the case for building strengthens.

If none of those three hold, building is likely to recreate capabilities that already exist — slowly, and at higher cost. That's the case when decisioning is necessary but not your differentiation, when you'd be staffing a project rather than a product, when your stack is conventional. It's not a failure of your team. It's a misread of what the work actually is.

The real question: total cost of industrialization, not POC cost

The build-vs-buy debate is almost always framed wrong. It compares the cost of the POC — a few weeks of a data scientist's time — against the annual license of a platform. On that comparison, building always wins. But the POC is not the cost. Industrialization is the cost, and it is invisible at the moment you decide.

The honest comparison is the five-year total cost of ownership of a production decision layer:

• The integration engineering to connect every operational system, bidirectionally, and keep it running
• The product work to build and maintain an editable business-rule layer across categories and countries
• The platform engineering to close and operate the execution-and-learning loop
• The permanent team to own all of the above, year after year, including the cost of attrition
• The opportunity cost of every season your team spends building plumbing instead of improving decisions

Against that figure, the platform license is rarely the expensive option. The expensive option is the build that consumes two years of your best engineers and ships late. It arrives as a one-directional recommender that operations don't trust — the data-graveyard outcome the POC made look impossible.

The question to put on the table is not "can we build it?" You almost certainly can. It is "should we own the industrialization and maintenance of a decision platform for the next five years — or is that effort better spent on the decisions themselves?"

The honest conclusion

Build if decisioning is your edge, you can fund a product team for the long run, and your stack defeats every platform. Otherwise, buying the layer and pointing your data team at the decisions — not the plumbing — is almost always the higher-leverage choice. Once you lean toward buy, our buyer's guide lays out the criteria, and our consulting vs platform comparison frames the parallel question every CFO asks next. The POC was never the thing. The industrialization always was.

For the ROI and budget questions CFOs face when evaluating a decision platform, see our CFO FAQ.

---

Pressure-test your build-vs-buy case

At Solya, we offer data and operational leaders a 30-minute diagnostic to stress-test a build-vs-buy decision against your own context — your stack, your team, your rule complexity. No generic pitch: an honest read on whether build or buy fits your situation.

You'll walk away with:

• A realistic five-year industrialization cost estimate for building in-house
• A map of where your stack and rule complexity would help or hurt a build
• A clear read on whether decisioning is differentiating enough to justify owning it