The Build-Everything Thesis

The claim

“Everything” is the direction. We write the applications and the libraries they use. What remains outside is named: hardware, operating systems, public networks, and development tools. There is no hidden graph of other people's packages between our code and those boundaries.

The documents that follow take inherited habits — borrow the library, rent the service, split the system, wrap it, describe it in a wiki — and ask whether they still earn their keep.

Why this used to be a bad idea

For most of software history, writing common infrastructure yourself was the wrong call. Engineers were expensive. A mature TLS stack or a PDF parser took years. Borrowing was sound economics.

Most of the modern stack answers the same question: how do we avoid writing expensive code? Package managers, software services, cloud platforms, and frameworks trade money, control, or complexity for time.

That premise moved. Language models can cut the time to a first implementation of a well-specified problem. The first draft is no longer always the expensive part. Specifying the work, reviewing it, testing it, and standing behind it still are. When the costly step gets cheaper, decisions made to avoid it are worth another look.

Models do not own the result. A person remains responsible for every line. That is enough to change many build-versus-buy calls. How we treat generated work is the subject of the Anti-Slop Manifesto.

Code and ownership

Our library is a lot of code. The question is not only how much an application uses. It is who owns it, and who can change what you ship.

A conventional package graph is work from many maintainers, each with their own release process. Our applications use code maintained by the people who ship the product. No outside maintainer publishes into the next build. The code changes when we change it.

We did not eliminate code. We replaced a graph of strangers with code we can read and repair.

Four arguments

The manifestos make four connected cases.

• Trust. Borrowed code, bought services, and unverified patches ask us to run work we do not control. — Anti-Dependency, Anti-CVE, Anti-Vendor, Anti-Slop.
• Simplicity. Unused generality adds code, layers, and delay. Removing it makes systems smaller, faster, and easier to follow. — Anti-Complexity, Anti-Abstraction, Anti-Bloat, Anti-Latency.
• Infrastructure. Cloud, containers, services, and monitoring stacks solve real operating problems. A compact system needs less of that machinery. — Anti-Cloud, Anti-Container, Anti-Microservice, Anti-Observability.
• Coordination. Every extra boundary is another handoff, and another place the story dies. Ownership keeps the work close to the people who have to live with it. — Anti-Headcount, Anti-Migration, Anti-Config, Anti-Documentation.

What this is not

Every company does not need to rewrite every dependency. Existing systems have migration costs. Many teams should keep buying mature capabilities. We are saying “build” is a reasonable answer more often than the industry assumes.

We still depend on platforms and public standards. The claim is bounded: for application capabilities we can own responsibly, the arithmetic has moved.

Our code has bugs, like all code. The difference is ownership. We can find them and repair them, and outside application packages do not enter production unless we put them there.