--- id: 33 title: "Are LLMs swinging us away from prepackaged services?" status: current kind: signal date: 2026-06-12 authors: - "Theo Zourzouvillys" tags: [llm, architecture, open-source, industry] summary: "A signal: LLMs may be swinging build-vs-buy away from prepackaged services. A generic complex service used to beat building until real scale; now building what you need is cheap. Maybe open source becomes shared architectures an LLM implements per user — like C replaced ASM." supersedes: null superseded_by: null aliases: [] --- ## 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](/zfn/31-own-your-components/)). 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](/zfn/23-iterate-and-rewrite-implementations/)). 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](/zfn/28-llm-brute-force-prs-understanding/)) — and you still use the standard *protocols* ([ZFN-30](/zfn/30-use-standards-dont-reinvent/)). 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](/zfn/28-llm-brute-force-prs-understanding/), **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](/zfn/28-llm-brute-force-prs-understanding/) 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](/zfn/31-own-your-components/) 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](/zfn/28-llm-brute-force-prs-understanding/)); 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](/zfn/31-own-your-components/) — owning components over generic services; this signal is that trend's possible acceleration. - [ZFN-23](/zfn/23-iterate-and-rewrite-implementations/) — LLMs make implementing/re-implementing cheap, the mechanism behind the shift. - [ZFN-30](/zfn/30-use-standards-dont-reinvent/) — even if implementation moves to the LLM, the standard protocols/formats stay. - [ZFN-28](/zfn/28-llm-brute-force-prs-understanding/) — the understanding gate that bounds how far this can safely go. ## Changelog - **2026-06-12**: Opened as a signal.