Build vs. buy changed in 2024. Your RFP hasn't noticed.

The build-vs-buy math flipped in 2024, and most enterprise RFPs still price it with a 2019 spreadsheet. AI-augmented teams of roughly twenty engineers now build and operate the software that used to demand hundreds. Buy still wins for undifferentiated commodities — payroll, the accounting core, email. Everything close to your route-to-market is now cheaper to own than the license-plus-integration bill suggests. The trap is scoring the build with headcount assumptions that expired two years ago.

What actually changed in 2024?

Lean teams shipping at planetary scale is not new. Back in 2014, WhatsApp served 450 million users with 32 engineers — one developer for every 14 million users. As of late 2025, Telegram reportedly runs a billion-user service with about 40 people. Both pulled it off the same way: brutal scope discipline, one product, and a refusal to hire their way out of hard problems.

What changed in 2024 is that the same discipline now stretches across a much broader surface. AI augmentation — code generation, review, test scaffolding, data migration — lets a small team hold more scope per head. The clearest public example is Claude Code, which The Pragmatic Engineer documents as reaching a $1 billion revenue run-rate within roughly six months, built by a core team of about ten engineers for most of 2025. The ceiling on what twenty people can build and run did not creep up; it jumped.

The caveat matters: AI augmentation multiplies a capable team, it does not conjure one. Twenty engineers who understand distributed systems, returnable-asset accounting and the edge cases of a dozen operating companies will outbuild two hundred who are still learning the domain. The step-change lands on judgment and taste, which do not come from a model. Read the small-team numbers as "software is now free" and you will underscope, then stall six months in.

For a route-to-market suite — order capture, stock, loyalty, returnables, delivery and analytics on one event bus — that jump is the entire argument. You are not asking twenty engineers to invent a database. You are asking them to compose well-understood patterns across a bounded domain, with AI absorbing the mechanical volume that used to justify a 200-person org chart.

Why do most RFPs still get the build number wrong?

Because the anchor in every "build is too expensive" slide is a category-proving number, not an operating number. When the world's largest brewer set out to prove that a brewer-owned B2B platform could work at all, it took more than 1,200 developers across 2019 to 2021 to stand it up and reach global scale. That figure was the cost of proving an entire category from zero, in the pre-AI era, while simultaneously inventing the operating model.

Copy that number into a 2026 RFP and it does two dishonest things. It treats the one-time cost of proving the category as the recurring cost of operating a suite. And it assumes 2019 per-engineer output, ignoring the productivity step-change that the WhatsApp, Telegram and Claude Code figures all point at. The result is a spreadsheet that makes the build look like a 1,200-person moonshot when the honest steady-state number for a defined scope is closer to twenty.

Vendors are not neutral here, and they rarely volunteer the correction. A build estimate that still assumes a 200-person org chart is the single most effective slide in an enterprise software sale, so it survives in RFP templates long after the economics underneath it moved. Nobody on the buy side is paid to challenge it, and the one group that could — your own engineers — is usually not in the room when the model gets built.

Where does buying still win?

Owning everything is the opposite mistake. Buy — and keep buying — anything that does not differentiate how you get product to a customer. The line is not "important versus unimportant"; payroll is important. The line is whether the domain is a commodity where every serious vendor has already converged on the same answer.

The financial core is the sharpest case. Your auditors already trust it, the compliance surface is enormous, and there is zero commercial upside to reimplementing general-ledger postings. Keep the SAP core exactly where it is and let the platform emit events into it. That fight buys no differentiation, because there is none to be had.

How do you fix your build-vs-buy model?

Rebuild the comparison from the domain up, not from a vendor's template down.

1. Re-baseline the build number. Estimate the steady-state team for your actual scope at AI-augmented output — not a 1,200-developer, category-proving figure. Prove-cost and operate-cost are different lines; do not let the RFP quietly merge them.
2. Draw the line at the event bus. Everything that reads or writes route-to-market events is a candidate to build; everything else is a candidate to buy. Our note on one event bus versus a middleware translation chain explains why that boundary, not the org chart, should decide.
3. Keep the financial core and prove the audit trail. Do not rebuild what auditors already accept. An event-sourced platform gives you a stronger trail than most bought systems — see why an event stream is an audit trail your auditors will like.
4. Price the integration tax of buying honestly. A bought suite still has to be wired into your bus, your operating companies and your financial core; that middleware chain is a recurring cost the license quote leaves off the page.
5. Compare on cost-to-serve, not license price. The figure that should decide this is cost per order served end-to-end — the metric in our cost-to-serve breakdown — not the annual license line.
6. Prove it on one scope before you commit. Run a scoped pilot on a single operating company and one workflow, and measure the real build-and-operate cost instead of arguing about it in a boardroom.

Heading into 2026, the interesting question is no longer whether twenty AI-augmented engineers can build and run a route-to-market suite; the public precedents have already settled that. It is which twenty, on which scope, reporting to whom — and whether your next RFP is honest enough to weigh that against the fully-loaded, integration-inclusive cost of the thing you were about to buy. The teams that re-baseline first will spend the rest of the decade owning the software their competitors are still licensing.