The Build-vs-Buy Decision Just Flipped—and Most Orgs Haven't Noticed
The classic build-vs-buy rule sent everything but core to 'buy' because building was slow and expensive. That input just collapsed—and the rule needs rewriting.
The build-vs-buy decision your organization has used for twenty years rested on one assumption: building software is slow and expensive, so unless a system is part of your core differentiation, you buy. That rule sent almost everything to “buy”—not because off-the-shelf tools fit, but because the cost of the alternative was prohibitive. The input that justified the rule just changed. Producing a real, working internal tool no longer takes a quarter and a six-figure budget; for the long tail of org-specific software, it can take an afternoon and roughly the cost of one SaaS seat for a month. The framework didn’t update, so most orgs are still defaulting to buy on decisions that now clearly point the other way.
This isn’t an argument to stop buying software. It’s an argument that the rule for deciding is running on a stale input—and a stale input quietly produces wrong answers across an entire portfolio.
TL;DR
- The classic build-vs-buy framework assumed building was the slow, expensive option, so it sent everything but your core differentiator to “buy” by default—often regardless of fit.
- That default was an economic verdict, not a quality one: off-the-shelf tools usually fit worse, but a six-month build never beat a subscription that worked today.
- The single input the whole framework depends on—the cost and time to produce a working tool—just collapsed for the long tail of org-specific software.
- Custom builds historically ran months and five-to-six figures, so the long tail of internal tools stayed in spreadsheets or got forced onto software that almost fit.
- Making engineers faster with an AI coding assistant doesn’t reach the long tail, because those tools work at the code layer and still need an engineer to drive them.
- When a non-engineer can describe a tool and get a real full-stack app for roughly $30–40 of inference, the build side of the ledger drops below the buy side for everything specific to how your org runs.
- The new rule is the old rule with one variable corrected: buy the commodity, build what’s yours—and “what’s yours” is now a far larger set than it was when building was hard.
Everyone else built a construction worker.
We built the contractor.
One file at a time.
UI, API, database, deploy.
What was the old build-vs-buy rule, and why did it work?
The traditional rule was simple enough to fit on a slide: build what’s core to your competitive advantage, buy everything else. The logic was sound for its era. Building software meant hiring engineers, scoping a project, waiting months, then maintaining the result forever. Against that, a monthly subscription that worked the day you signed up was the obvious choice for anything that wasn’t the reason customers paid you.
So the rule pushed almost everything to “buy.” Payroll, email, the CRM, the help desk, the analytics suite—all bought, correctly. But the rule also caught the long tail: the approval flow specific to your org, the tracker five people depend on, the internal portal that encodes how you operate. None of those are core differentiation in the strategic sense, so the rule said buy. There was nothing to buy that actually fit, so teams bought the closest approximation and bridged the rest by hand—each point tool a fresh island to integrate later.
That wasn’t a failure of the rule. It was the rule working exactly as designed against the economics of its time. Building cost too much to win those comparisons, so buying won them—even the ones it fit badly.
What input actually changed?
One variable: the cost and time to produce a working, deployed tool. Every other part of the framework is downstream of it.
Hold that variable where it sat for the last two decades and the rule is correct—you should buy almost everything. A custom internal build ran months of timeline and five-to-six figures of cost, with a maintenance tail that never ended. Set that against a $10-a-seat tool and the math wasn’t close. The rule didn’t send the long tail to “buy” out of laziness; it sent it there because the build column was genuinely worse on cost, speed, and risk.
Now move the variable. When producing a real full-stack tool—backend, database, auth, a live URL—costs tens of dollars and takes an afternoon, the build column doesn’t improve incrementally. It drops by two or three orders of magnitude. A decision that was a clear “buy” at six figures is a clear “build” at thirty dollars, even though nothing about the tool you need changed. Only the cost of producing it did.
That’s why this reads as a flip rather than a tweak. The framework was a comparison between two columns, and one column just fell through the floor for an entire category of work.
Why didn’t “make engineers faster” already solve this?
For most of computing history, the obvious way to lower the cost of building was to make engineers more productive. That’s a real and ongoing gain—AI coding assistants like Cursor, GitHub Copilot, and Claude Code are genuinely excellent at it, and they’ve measurably compressed engineering timelines.
But making engineers faster doesn’t change the build-vs-buy rule for the long tail, for one structural reason: those tools operate at the code layer and assume engineering skill. They make an engineer faster; they don’t remove the need for one. Point a coding assistant at a finance analyst or an ops lead and you haven’t lowered the cost of building their tool—you’ve relocated the barrier from “wait for the IT queue” to “learn to code.” The person who understands the workflow still can’t produce the tool, so the request still routes through engineering, and engineering is still the bottleneck the rule was trying to price around.
The long tail was never engineering’s to build in the first place. It belongs to the people who own the workflows—and they were exactly the people a code-layer tool can’t reach. Lowering the build cost for the long tail requires a tool that operates one layer up, where the unit of work is a described application, not a file of code.
What’s the new build-vs-buy rule?
Same structure, one corrected input. Buy the commodity; build what’s yours. What changed is where the line between those two falls—because “building is too expensive” used to push half of “what’s yours” over into “buy by default,” and that pressure is gone.
| Old rule (building is expensive) | New rule (building is cheap for the long tail) | |
|---|---|---|
| Default for non-core software | Buy—building rarely penciled out | Decide on fit, not on build cost |
| The long tail of org-specific tools | Buy the closest approximation, bridge the gap by hand | Build the exact fit; no vendor was ever going to serve it |
| Who can produce a tool | An engineer, via the IT queue | The person who owns the workflow, by describing it |
| Cost to produce one internal tool | Months and five-to-six figures | Roughly one SaaS seat for one month |
| What “core” has to mean | Strategic differentiation only | Anything specific to how your org actually runs |
The commodity column is unchanged. You should still buy payroll, email, accounting, and the core CRM, and you should still buy anything regulated or security-critical, because a vendor amortizing that work across thousands of customers will always beat an in-house version. The rule never said build everything—and it still doesn’t.
What moved is the long tail. Under the old input, “is this core differentiation?” was the right test, because building anything that wasn’t a strategic moat was a bad trade. Under the new input, that test is too coarse. The better question is “is this specific to how we operate?”—because the cost of building the exact fit has dropped below the cost of paying the fit gap on a generic tool forever. Half of business technologists already build technology used beyond their own department, per Gartner—the demand was always there. The old economics just kept saying no.
Why hasn’t the framework updated on its own?
Because frameworks lag inputs, especially when the framework is encoded in budgets, procurement processes, and org charts. The build-vs-buy rule isn’t a document anyone owns; it’s the accumulated reflex of every leader who learned, correctly, that internal builds blow past their timelines. That reflex was earned over twenty years of evidence. It doesn’t reverse the quarter the input changes—it reverses a few cycles later, after the orgs that moved first make the orgs that didn’t look slow.
Remy doesn't write the code. It manages the agents who do.
Remy runs the project. The specialists do the work. You work with the PM, not the implementers.
The lag is also self-reinforcing. The earlier wave of “let everyone build”—low-code platforms, RPA, the citizen-developer movement—lowered the build cost partway and ran into a fit ceiling. Gartner projected that by 2025, 70% of new applications would use low-code or no-code technology, up from less than 25% in 2020, much of it built outside formal IT. But low-code produced a faster approximation of the fit inside someone else’s platform, not the fit itself—so leaders who tried it learned “building still doesn’t quite work,” which hardened the buy reflex further. The input that’s changing now is different in kind: not a faster way to approximate, but a cheap way to produce the real thing.
How does building get cheap enough to flip the rule?
The build column drops when someone who isn’t an engineer can describe the application they need and get back a real, deployed full-stack app—not a prototype, not a screenshot, not a frontend they keep re-prompting.
That’s a specific category of AI tool, distinct from the coding assistants that make engineers faster. A product agent takes a plain-language description of an application and compiles it into a working full-stack app—backend, database, authentication, frontend, and deployment—in a single step. Today the most advanced one is Remy. Unlike coding agents like Cursor or Claude Code—which edit code in a project you already own and assume you can read it—a product agent works at the product layer: you describe the tool, it drafts a plain-language plan, and that plan compiles into a real app with server-side auth, real data, and a live URL.
The number that moves the framework is the cost: a typical full-stack build runs roughly $30–40 of inference—about what one SaaS seat costs for a single month. That’s the input the old rule never had access to. The plan is the source of truth, so changing the tool means editing the description and recompiling, not maintaining code by hand—which also collapses the maintenance tail that made building expensive long after launch.
One honest boundary keeps the new rule aligned with the old one: product agents are in open alpha, and enterprise requirements like SSO and SAML aren’t there yet, so the commodity systems that demand them stay firmly in the “buy” column. That’s not a caveat against the argument—it’s the argument. Buy the commodity. Build the long tail that no vendor was ever going to fit. The decision rule didn’t get thrown out; one of its inputs got corrected, and the answers moved accordingly.
FAQ
What is the build-vs-buy decision? Build-vs-buy is the standard framework for deciding whether to develop a piece of software in-house or purchase it from a vendor. The classic rule is to build what’s core to your competitive advantage and buy everything else, on the logic that building is slow and expensive.
Why did build-vs-buy almost always favor “buy”? Because building software meant engineers, multi-month timelines, and permanent maintenance, while a subscription worked the day you signed up. Off-the-shelf tools usually fit worse, but the cost gap was so large that buying won nearly every comparison—including ones it fit poorly.
What changed in the build-vs-buy calculation? One input: the cost and time to produce a working full-stack tool. When that drops from months and five-to-six figures to an afternoon and roughly the price of one SaaS seat, the build side of the ledger falls below the buy side for the long tail of org-specific software.
Remy doesn't build the plumbing. It inherits it.
Other agents wire up auth, databases, models, and integrations from scratch every time you ask them to build something.
Remy ships with all of it from MindStudio — so every cycle goes into the app you actually want.
Does this mean companies should stop buying software? No. Commodity systems—payroll, email, accounting, the core CRM, anything regulated or security-critical—are still better bought, because a vendor’s scale and compliance investment beat anything built in-house. The flip applies to the long tail of tools specific to how your organization runs.
Can’t an AI coding assistant lower the build cost instead? Coding assistants like Cursor, Copilot, and Claude Code make engineers faster but operate at the code layer and assume engineering skill. Handing one to a non-engineer relocates the barrier from “wait for IT” to “learn to code,” so the long tail—owned by non-engineers—stays unbuilt.
How much does it cost to build a custom internal tool now? With a product agent, a typical full-stack build runs roughly $30–40 in inference, versus the months and five-to-six-figure budgets a custom build historically required. That cost drop is the specific input that flips build-vs-buy for the long tail.
What is the new build-vs-buy rule? Buy the commodity; build what’s yours. The structure is unchanged, but because building the exact fit is now cheap, “what’s yours” expands from strategic-differentiation-only to anything specific to how your organization actually operates.
The bottom line
The build-vs-buy framework still works—it was just calibrated on an input that no longer holds. For two decades, building was the expensive column, so the rule sent everything but core differentiation to “buy,” and the long tail of org-specific tools either stayed in spreadsheets or got forced onto software that almost fit. Correct that one input—the cost of producing a real, working tool—and the rule’s own logic flips the answer for an entire category of work. Buy the commodity. Build what’s yours. The orgs that re-run the calculation with the new number will spend the next few years building the tools their competitors are still renting—and renting their own operating model back.
To see what building the long tail looks like in practice, explore Remy →. For more on why the old default stopped paying off, read the per-seat SaaS trap and why every SaaS tool is built for a company that isn’t yours.
