Build vs Buy

When agents make custom software cheap to produce, the build-versus-buy line moves. Tools once too expensive to build in-house become viable, and some teams begin replacing SaaS with internal alternatives -- but cheap to build is not cheap to own.

The Pattern

When agents make custom software dramatically cheaper to produce, the build-versus-buy threshold shifts. Capabilities that were previously "just buy the SaaS" -- because building wasn't worth the engineering time -- become viable to build in-house, and some teams start replacing third-party tools with internal alternatives tailored to exactly their workflow (BCG Platinion). Dan Shapiro frames the underlying force as "technical deflation": the cost of producing code is dropping fast enough that the smart move is to "defer payment on human hours today to pay them back with cheaper AI hours tomorrow" (The Five Levels). The cost curve for build has moved down hardest for the unglamorous middle -- internal tools, integrations, data pipelines, and workflow automation -- which is exactly the territory SaaS used to win by default (SAgentLab).

Why It Matters

The shift is real but easy to over-read. Cheap to build is not cheap to own. Internal software still needs maintenance, security, compliance, and on-call -- and going DIY means taking responsibility for "all aspects of compliance and data protection yourself" rather than inheriting them from a vendor (Bernard Marr, Forbes). For agentic systems the ownership cost is worse than for ordinary SaaS, because the underlying tech moves so fast that today's architecture is obsolete in a couple of quarters. One vendor argues the honest framing is not "build vs buy" but "build, build, build, build, build vs buy" -- a permanent team "forever rebuilding to keep pace," whose real cost is "what else those engineers could be building" (Lorikeet, vendor; they sell the buy side). That self-interest cuts both ways, but the opportunity-cost point stands: the sharpest question is no longer "can we afford to build it" but "do we want to own it forever."

The defensible position is per-use-case, not company-wide -- and often per-layer within a single use case. Buy when the capability is a vendor's core competency, your workflow matches most of the default, and lock-in or differentiation don't matter much; build when differentiation lives in the workflow itself, you need control over sensitive data, or the alternative is brittle UI-based configuration (SAgentLab). The decision rarely has to be all-or-nothing: Jurgen Appelo's rule of thumb is to "rent the plumbing but keep the memory, logs, and control plane under your roof" -- outsource the commodity infrastructure, own the parts that carry your context and differentiation (Appelo). The build option got cheaper, so it deserves reconsideration on more cases -- not that buying is dead, and not that every internal tool an agent wrote in a week is one you should still be running in a year. This decision sits alongside calculating ROI and cost management, and the in-house path leans heavily on the agentic platform you can actually staff.

Last reviewed: 2026-06-25