The Build-Everything Thesis

This is the claim the other sixteen documents defend. We state it once, plainly, here: we wrote all of our software ourselves. The application code, the libraries it stands on, the protocols it speaks, the formats it parses — all of it, with zero third-party dependencies. Each manifesto that follows removes one piece of the conventional stack and shows the work. This document explains why removing every piece at once is not recklessness. It is the rational response to a change in the cost of writing software.

1. The claim, precisely

“Everything” is not rhetoric. The Virtually Unlimited Library is hundreds of modules and millions of lines of code, spanning cryptography, TLS, networking, compression, data formats, image and document processing, databases, authentication, and numerics. The complete bill of materials for an application built on it has four entries: your code, our library, the language runtime, and the operating system. There is no dependency graph beneath that line. Two engineers wrote it — and shipped production applications on it at the same time.

The sixteen manifestos are the itemized defense. Each takes one inherited assumption — that you borrow libraries, buy SaaS, rent cloud, split into services, wrap in containers, document in wikis — and re-derives it from first principles.

2. Why this was irrational until recently

For most of software's history, building from scratch was the wrong call, and everyone knew it. Engineers were expensive and slow; correct implementations of hard things — a TLS stack, a PDF parser, an OAuth server — took specialists months. Against that cost, borrowing was obviously right. “Don't reinvent the wheel” was not a slogan. It was sound economics.

Every default in the modern stack is an answer to the same question: how do we avoid writing expensive code? Package managers, SaaS subscriptions, managed cloud, frameworks — each one trades money, dependencies, or complexity for engineering time you could not otherwise afford.

That premise changed. Large language models can reduce the implementation cost of well-specified problems, sometimes dramatically. Writing the first implementation is no longer always the dominant cost. Specification, review, testing, maintenance, and accountability remain. When one part of the cost falls, decisions made to avoid it are worth re-examining. The sixteen manifestos are that re-examination, carried to its conclusion.

This is not a claim that the models write the software unsupervised. They do not — a human takes responsibility for every line. It is a claim that the labor cost that justified the entire borrow-don't-build stack has collapsed, and that the stack should be reconsidered accordingly.

3. “But your library is a dependency too”

This is the first objection everyone raises, and it deserves a direct answer rather than a clever one. Yes: millions of lines is a great deal of code, and we depend on every line of it. But the relevant question is not how much code you depend on. It is what kind of dependency it is.

A conventional application can depend on hundreds or thousands of packages it did not write, drawn from a transitive graph maintained by people outside the shipping team. Our application depends on one body of code written by the team that ships it, with no transitive package graph and no outside maintainer publishing into the next build. It changes when we choose to change it.

Those are not the same risk at different sizes. They are different ownership models. We did not eliminate code. We replaced a graph of outside maintainers with code owned by the shipping team.

4. The four threads

The sixteen manifestos fall into four arguments. Each is a different face of the same decision.

• Trust. You cannot audit code you did not write and cannot read. Dependencies, CVEs from upstream, SaaS vendors, and AI-generated drive-by contributions are the same problem wearing four hats: running code, or trusting people, you have no basis to trust. — Dependency, CVE, Vendor, Slop.
• Simplicity. Layers, configuration, abstraction, and bloat are the accumulated cost of generality you do not use. Remove the generality and the system becomes small, fast, and comprehensible. — Complexity, Abstraction, Bloat, Latency.
• Infrastructure. Cloud, containers, microservices, and observability platforms are machinery for systems too complex to operate by hand. A single static binary on a single server needs almost none of it. — Cloud, Container, Microservice, Observability.
• The team. Headcount, migrations, config sprawl, and documentation rot are overhead that scales with the size of what you borrowed. A small team that wrote the system shares direct context about how its parts fit together. — Headcount, Migration, Config, Documentation.

5. What this is not

This is not a claim that every company should rewrite every dependency tomorrow. For most teams, on most days, the old economics still partly hold and the migration cost is real. The thesis describes a curve that has crossed, not a switch that everyone must flip at once.

It is not “not invented here” as a reflex. We use the operating system. We use the language runtime. We use the CPU's instruction set and the network. The claim is bounded: for the broad class of capabilities that most applications actually need, the build-versus-buy calculation has inverted, and we built accordingly.

And it is not a claim that our code is free of defects. It has bugs, like all code. The difference is that there is exactly one place to find them, one team to fix them, and no version of the problem in which a flaw three dependencies deep — in code no one on the team has ever read — reaches production without anyone choosing to put it there.

This is the thesis. The documents that follow are the proof. Read the manifestos →