Skip to content
Claude for Supply Chain
AI for Supply ChainPlatform decision

AI for Supply Chain Build or Buy

The Build or Buy decision in supply chain planning has changed. Generative AI sharply reduced the cost of building the interface layer. It did not reduce the cost of building and sustaining the calculation engine. If you do not separate the two, you will make the wrong decision.

For years, the question was simple to ask, even if difficult to answer: buy a ready-made platform or develop one internally. Both paths required significant investment, time, a team and an architectural decision that was difficult to reverse.

That is no longer true across the entire stack. One specific part of the work became inexpensive, while another remains just as costly as before. The mistake today is treating a planning platform as a single block and applying to the whole a conclusion that is only true for half of it.

The thesis behind this article is the same one behind the program: AI is an interface, interpretation and orchestration layer over deterministic engines. It is not a replacement for calculation. Put calculation inside a language model and you lose reproducibility and auditability—usually discovering it too late.

The starting point

What became cheaper—and what did not.

This separation is the first filter in any Build or Buy assessment today. Without it, the business case mixes two kinds of work with completely different cost and risk curves.

Cheaper to build today
  • Unstructured context capture
  • Exception triage and prioritization
  • Explaining why the plan looks the way it does
  • Drafting communications and scenarios
  • KPI and variance narratives
Still expensive and risky
  • MRP with correct netting and pegging
  • Multi-echelon safety stock
  • Finite-capacity scheduling
  • Statistical forecasting engines

The right-hand column requires determinism, reproducibility and auditability. The same inputs must produce the same plan, and that plan must remain explainable line by line months later. Those properties still require specialized engineering, validation and support. Generative AI did not eliminate that cost.

The practical consequence is direct. If your operational pain sits in the left-hand column, building is now a real alternative, at a cost and speed that did not exist before. If the pain sits on the right, the economics have not changed: building a planning engine remains a multi-year project with strong dependence on scarce talent.

Most companies have pain in both columns, in different proportions. That is why the honest answer is rarely pure Build or pure Buy.

Designing the boundary

Four lenses for designing the boundary.

No single criterion can draw the line between Build and Buy. The decision becomes more robust through four independent lenses: rate of change, criticality and differentiation, market maturity and vendor dependency.

  1. 01

    Rate of change

    Separate applications by how quickly they change, not by function. What changes over decades holds master data and critical transactions. What changes over years carries company-specific capabilities. What changes over months exists to test hypotheses and should not carry project-level governance.

    In planning, the split is direct. Deterministic engines are the slow layer: buy and protect. AI is the fast layer: build and replace freely. Governing both with the same rules either freezes the top or destabilizes the bottom.

    1. Systems of record

      Rate of change
      Changes in decades
      Examples
      MRP, finite capacity, master data, transactions
      Recommendation
      Buy and protect
      Rationale
      Requires determinism and auditability. The market has solved it; customization adds risk without differentiation.

    2. Differentiation

      Rate of change
      Changes in years
      Examples
      Proprietary business rules, inventory policy, prioritization logic
      Recommendation
      Build or extend
      Rationale
      This distinguishes your operation. No vendor delivers it ready-made, and locking it into a third-party product sacrifices flexibility.

    3. Innovation

      Rate of change
      Changes in months
      Examples
      Conversational interface, exception triage, plan narrative
      Recommendation
      Build
      Rationale
      Changes too quickly to become a project. Build it, version it lightly and accept that it will be replaced.

    The difference is not only what to build. Each layer requires a different management regime.

    How the management regime changes from Record to Differentiation and Innovation.Hover over or select a layer.
    1. Process change
      Strict controlExperimentation
    2. Architecture
      TraditionalAlternative platform
    3. Investment
      Corporate budgetDepartmental
    4. Project type
      WaterfallAgile
    5. Governance
      CorporateSpecialist team

    From left to right, the regime loosens across all five dimensions. Dark marks strict management, gray the transition and light the flexible regime.

  2. 02

    Criticality and differentiation

    Cross criticality with differentiation. Critical capabilities must work; differentiating capabilities deserve your best people. Planning engines often land in the awkward combination: too critical to fail, too generic to justify proprietary development.

    Business rules and decision experience sit at the other extreme: they carry knowledge specific to your operation. That is where building starts to make sense.

    What differentiates and what is merely necessary.Select a quadrant.

    Focus your best people on differentiation. Buy, automate or minimize the rest.

    Horizontal: differentiation. Vertical: criticality. Position determines strategy.

  3. 03

    Market consolidation stage

    Position each component from emerging to commodity and derive sourcing from that position: build what is new, buy what has become a product and consume commodities as services.

    Solvers, optimizers and MRP are mature markets. Conversational interfaces and agent orchestration are still forming. Building became more attractive precisely where the market has not consolidated a product.

    The more consolidated a component market is, the less sense it makes to build it.Select a stage.
    BuyMature productBuy

    A market consolidated over decades. Building means paying more to remain behind it.

  4. 04

    Where the vendor boundary sits

    Buying is not binary. It means deciding where the vendor ends and the capability that remains yours begins.

    With an expansive boundary, integration, rules, engine, interface, analytics and AI sit inside the platform. With a narrow boundary, the vendor supplies engine and interface while data, rules, analytics and AI remain under your control.

    The difference appears when something changes. In an expansive boundary, replacing the vendor changes much of the operation. In a narrow one, the purchased component is replaceable.

    Where the vendor boundary sitsHover over a component to compare.

    Buying is not binary. The decision is how much of your operation sits inside the vendor.

    Expansive boundary

    Vendor

    Capability lock-in

    The vendor supplies more than technology; it carries a material part of your operation.

    Changing vendors means changing part of the operation.

    Narrow boundary

    VendorIn-houseIn-house

    Replaceable component

    The vendor supplies engine and interface. Data, rules, analytics and AI remain under your control.

    Changing vendors means replacing one component.

The four lenses are not our invention; their sources appear below. What follows is ours: translating them into supply chain planning, defining the criteria, weights and scoring method.

The NEO framework

NEO Build or Buy Framework

Five criteria that turn an architecture debate into an objective decision.

NEO developed the criteria, weights and scoring method from real planning projects. The model is proprietary, but it is not a black box: the criteria are explicit, the weights can be debated and every answer requires evidence from the operation itself.

A framework that does not expose its own criteria cannot be audited.

Filter by criterion

Select a criterion to read it on its own.

  1. 01

    Cost

    Five-year total cost

    What to investigate: every cash outflow over five years, not only the license or first-year team cost. Include licensing, development, infrastructure, integration, version upgrades, data rework, internal IT hours, training and support.

    Support is the most common blind spot. Do not budget only for the build: accumulated support in later years often exceeds the initial investment, yet rarely appears in the financial model behind the decision.

    The test is simple: ask for the isolated year-three cost in both scenarios. If nobody can answer without rebuilding the calculation, the business case is not ready to decide anything.

  2. 02

    Flexibility

    Flexibility to change business rules without a project

    What to investigate: how long it actually takes to change an allocation rule, prioritization criterion or inventory policy. Use the real elapsed time from the last change, including prioritization queue, validation and deployment window.

    Supply chain rules change faster than the IT project cycle can support. A rigid platform turns every adjustment into a formal request, leaving operations with the wrong rule for months. A poorly architected internal system creates the same problem with an internal queue.

    A common mistake is confusing screen configurability with rule flexibility. Renaming a field is not the same as changing how the plan is calculated.

  3. 03

    Risk

    Execution and key-person risk

    What to investigate: how many people understand enough to run and evolve the solution alone. If the answer is one or two, the dependency is already material.

    Large IT projects carry schedule, budget and scope risk, whether implementing a platform or building internally. Time to first production value matters too: initiatives that remain invisible for too long lose sponsorship before completion.

    The best predictor is not the plan’s optimism but the company’s own project history. What happened in the last comparable implementation? What shipped, what slipped and what was abandoned?

  4. 04

    Maturity

    Data and planning-process maturity

    What to investigate: master-data reliability—lead times, BOMs, production calendars, resource capacity and inventory policies. Do not ask whether the field exists; ask whether its value reflects operational reality.

    Also determine whether the planning process is documented and stable, or depends on one person’s spreadsheet and unwritten adjustments.

    Poor master data is not fixed by a new system. The new system inherits it and produces wrong answers faster and with greater confidence.

  5. 05

    Ownership

    Who sustains the solution after go-live

    What to investigate: the name of the accountable person and function. Not a generic structure, “IT” or “vendor support.” Who specifically owns this in year two?

    The lists differ by path. Buying requires product ownership, configuration, releases, integrations and planning knowledge. Building adds code, architecture, infrastructure and evolution.

    Teams often assess the ability to go live, not the ability to sustain. If this question has no named answer before signing, it will have a poor answer afterward.

The outcome

Where your case lands between Build and Buy

The five criteria create a position on the axis. The result is more than a recommendation: it shows what pulled the decision each way, the principal risks and what needs to happen next.

First

Are the foundations strong enough to proceed?

If not

NO-GONeither Build nor Buy. Not yet.

The assessment stops here and identifies what must be in place before the decision makes sense. Establish the conditions before investing.

Possible reasons

  • Ungoverned master data
  • Unstable planning process
  • No named owner for support
  • Insufficient five-year return
  • Lack of executive sponsorship
  • Unacceptable execution risk

If yes

The case is positioned on the axis.

The five criteria are scored using operational evidence, placing the result in one of four positions between building and buying.

A framework that cannot produce this outcome is a sales funnel, not a framework.

← BuildBuy →

Select a position.

Next step

Find where your case lands between Build and Buy

Facilitated by NEO

Answer the five criteria with evidence from your operation. The assessment shows where your case lands, what pulled the decision each way and whether the foundations are strong enough to decide now.

The complete assessment, including weights and a criterion-by-criterion reading, is facilitated by NEO. Contact us directly to evaluate your case.

Falar com a gente

WhatsAppE-mail

If the result is NO-GO

Where to begin.

When the basis for a decision is missing, the gap is usually readiness or a quantified return. We offer both assessments.

ReadinessSupply Chain Diagnostic

Assesses readiness and maps opportunities: planning maturity, data quality and governance, sources of loss and prerequisites before investment.

Link coming soon

ReturnROI Study

Quantifies expected returns against five-year total cost, so the investment hypothesis can be supported—or rejected—with numbers.

Link coming soon

Disclosure

NEO works on both sides of this decision: implementing platforms and enabling internal teams to build. That is why the criteria and weights are published openly. The method can recommend Build, Buy, an intermediate position or conclude that neither path has adequate foundations yet.

Sources and further reading behind this section

Listed in the order in which the ideas appear. Public sources include where they can be found.

  1. 01

    Gartner. Pace-Layered Application Strategy, 2010.

    gartner.com

    Used in: Rate of change

  2. 02

    Moore, Geoffrey A. Dealing with Darwin: How Great Companies Innovate at Every Phase of Their Evolution, 2005.

    Used in: Criticality and differentiation

  3. 03

    Wardley, Simon. Wardley Mapping, 2005.

    docs.onlinewardleymaps.com

    Used in: Market consolidation stage

  4. 04

    Haberlah, David. Build vs Buy in 2026: Using Wardley Mapping to Navigate the Agentic AI Shift. Medium.

    Used in: Market consolidation stage

  5. 05

    Cochran, Tim; Gandhi, Prashant; Nygard, Carl. Build versus buy. ThoughtWorks, 2022.

    thoughtworks.com

    Used in: Vendor boundary

The diagrams are NEO’s interpretation of these sources as applied to supply chain planning. Any error of interpretation is ours, not the source’s.