Are LLMs swinging us away from prepackaged services?

The shift I’m noticing

For my whole career the build-vs-buy math has pointed firmly one way: for anything non-trivial, taking on a generic prepackaged service or library beat building it yourself — until you got to a certain size, where owning it finally paid (ZFN-31). The cost of implementing was so much higher than the cost of adopting that “don’t build it, pull it off the shelf” was almost always right.

I think LLMs might be swinging that pendulum, and I want to write the observation down while it’s still forming. As the cost of implementing exactly what you need drops toward the cost of describing it, the generic complex service — with all its generality you don’t use, its integration overhead, its dependency and lock-in — stops obviously winning. The balance that held for decades may be tilting, and at a much smaller scale than the old “certain size.”

The old balance

Why “buy” dominated for so long:

• Implementing was expensive. Building a robust version of a non-trivial capability — the edge cases, the hardening, the maintenance — cost far more than wiring in something that already existed.
• Generality amortised that cost across everyone. A prepackaged service spreads its huge build cost over thousands of users, so each one rents a sliver. That’s a genuinely good deal — when building your own is dear.
• So you accepted the overkill. You took the whole generic iceberg, used the tip, and paid in surface, assumptions, and lock-in, because the alternative — building — was simply more expensive.

The crossover point, where owning beat renting, only arrived at real scale: enough usage that the generic costs (per-unit pricing, the misfit, the dependency) finally outweighed a large in-house build.

What LLMs change

LLMs attack the exact term that made “buy” win: the cost of implementing. Building a focused, exactly-fits component — leaning on small vetted libraries for the genuinely hard primitives — is dramatically cheaper than it was, and re-implementing against a new constraint is cheap too (ZFN-23). If building exactly what you need is no longer the expensive option, the central reason to accept a generic service’s overkill weakens. The crossover point where owning wins slides down — toward much smaller teams and earlier stages.

(Important: this is not “build everything.” The understanding gate still binds hard — building what you don’t grasp is a disaster the tool makes easier, not safer (ZFN-28) — and you still use the standard protocols (ZFN-30). The shift is in the implementation economics, not in the need to understand.)

The hypothesis

Here’s the part I’m least sure of and most interested in. If implementation is becoming cheap and specialisable, the valuable shared artifact may stop being the generic implementation and become the domain-specific architecture — the hard-won design knowledge, the patterns, the data model, the protocol choices, the test suite — that an LLM then implements, tailored to each user’s specifics.

The analogy I keep reaching for: C replaced assembly. We moved up a level of abstraction, and the durable, shareable thing became the higher-level description rather than the machine-specific implementation; a compiler specialised it per target. An LLM may be a new kind of “compiler” from architecture + intent to implementation. If so, the future of open source might look less like “here is a generic binary/library you depend on” and more like “here is a precise, expert, domain-specific architecture and spec that an LLM realises for your exact context.” The reusable unit becomes the design, not the code.

Who this rewards

A second-order implication, and maybe the more important one. Organizations have typically scaled by adding hands — a larger and larger number of hands-on-keyboard developers, many necessarily lower-context, wiring together generic services and frameworks. That made sense while implementation was the expensive, parallelisable bottleneck: throw more people at it.

If this signal is right, the advantage shifts to teams of architecture, platform, and domain experts — people who deeply understand the domain, the protocols, scalability, and system design — who can, as a small team, own these services end to end. The leverage stops being “how many hands can we throw at it” and becomes “how much genuine understanding can a small group apply,” with LLMs as the multiplier on that understanding — and, per ZFN-28, only on genuine understanding. The org that wins isn’t the one with the most developers; it’s the one with the right deep experts, amplified.

This isn’t new — it’s how the strongest engineering orgs at large companies already work: small numbers of deep experts owning the critical platforms. What changes is where the line sits. The ability to do more with fewer, deeper people pushes that model down — to team and company sizes where it was previously unaffordable. (The flip side is a real risk: orgs that chase volume-of-hands without the depth will just produce more un-understood, LLM-built systems, faster — the ZFN-28 failure mode at organizational scale.)

What I’m watching for

Signals that this is real:

• Teams replacing generic SaaS/libraries with LLM-built, exactly-fit components — earlier and smaller than the old crossover (ZFN-31 becoming the default, not the exception).
• Smaller teams of deep architecture/platform experts out-shipping larger teams of lower-context developers — the winning org shape tilting from headcount toward concentrated understanding, at company sizes where that used to be unaffordable.
• Open source shifting weight from monolithic implementations toward specifications, reference architectures, domain models, and conformance test suites — artifacts an LLM consumes to generate a fitted implementation.
• “Generic complex service” value propositions eroding for anything that isn’t genuinely operational (i.e. where you’re buying running it, not just the code).

Why I might be wrong

• Services sell operations, not code. A lot of what you buy is someone running it — the scale, the security posture, the on-call, the compliance, the support. An LLM writes code; it doesn’t operate the service. That moat may hold even as implementation gets cheap.
• The understanding gap is real and limiting. Specialising an architecture safely still needs deep understanding (ZFN-28); plenty of teams will still be better off buying than owning something they don’t grasp.
• Ecosystems and network effects keep popular generic things winning beyond their raw cost.
• Maintenance of bespoke could become its own crisis — a world of un-understood, LLM-built components is not obviously better than a world of well-worn shared ones.
• And the honest one: pendulums swing, and it’s easy to over-read the early part of a swing. This is a signal, not a forecast I’d bet the company on.

References

• ZFN-31 — owning components over generic services; this signal is that trend’s possible acceleration.
• ZFN-23 — LLMs make implementing/re-implementing cheap, the mechanism behind the shift.
• ZFN-30 — even if implementation moves to the LLM, the standard protocols/formats stay.
• ZFN-28 — the understanding gate that bounds how far this can safely go.

Changelog

• 2026-06-12: Opened as a signal.