Build, Don't Buy
For decades the default was to buy SaaS for everything outside your core. AI moved the line. Build the tools that carry your taste and compound into an operating advantage, dogfood them on your own work, and rent only the commodity plumbing. The things you build become the substrate you build the next thing with.
The Thesis
The classic "build vs buy" calculus assumed engineering time was the scarce resource, so the answer for anything non-core was almost always buy. A design system, an automation runner, agent infrastructure — you paid a vendor because building one would cost a team months. The Golden Age inverted that: a single person with AI now builds in an afternoon what used to take a team a quarter. When the cost of building collapses, the build/buy line moves, and a large class of tools that used to be obvious buys become better builds — because what you build you own, you can shape to your exact taste, and you can keep using to build everything after it. Source: User, 2026-06-13
Kevin's version is not "build everything." It is build the differentiated layer; rent the commodity layer; dogfood relentlessly. The discipline is in where you draw the line. Source: User, 2026-06-13
The Line
| Build it yourself | Rent it |
|---|---|
| Carries your taste / point of view | Undifferentiated, everyone's is the same |
| Compounds — becomes a multiplier for the next project | Commodity plumbing with no moat |
| An agent operates it (so encoding your conventions matters) | Solved problem with a stable interface |
| Examples: Sigil UI (design system), Agent Machines (agent platform), Loop (skill operator desk), this wiki | Examples: Postgres ([[saas-stack-2026 |
This is exactly the line Loop's own README draws: "Product logic deserves the custom code. Infrastructure plumbing should be rented whenever possible … Managed primitives are a feature, not a compromise, when they let us spend time on the [differentiated work] instead of undifferentiated ops work." Source: loop/README.md "Shipping beliefs", 2026-06-13 Buying a database is not a failure of nerve; building your own database to run a SaaS app is the failure. Build where building buys you taste and a reusable edge; rent where it only buys you maintenance.
Agent systems: own the context, route the execution
For agent systems, the line must be drawn per layer. The portable moat is the combination of rules, skills, MCP/capability contracts, workflow manifests, source identity, approval policy, evaluations, and proof. Those should remain owned, inspectable, and replayable across Codex, Claude, Cursor, Hermes, and future runtimes. Models, sandboxes, low-level fleet operations, and hosted agent surfaces can be rented when the provider is replaceable and cannot become the only holder of canonical memory or decisions. Source: X/@davep X Article, 2026-07-27; Sierra Pinecone and MCP Gateway, July 2026
The cited companies establish both sides of the decision. Stripe's Minions and Sierra's Pinecone justify building because the system is strategic product infrastructure, Stripe already owned mature devboxes, and both systems are staffed and dogfooded indefinitely. Cursor's self-hosted Cloud Agents justify buying a different composition: the customer's code, tools, and network remain inside its infrastructure while Cursor owns orchestration, models, and UX. Neither case supports blindly building or blindly buying the whole stack. [Sources: Stripe Minions parts 1–2, February 2026; Sierra Pinecone, July 2026; Cursor self-hosted Cloud Agents and cloud-agent lessons, March–June 2026]
Before adopting an agent platform, answer four questions:
- Which layer contains Kevin-specific taste, context, policy, and accumulated evidence?
- Can all durable state and run proof be exported and replayed through another harness without scraping a vendor UI?
- Is the lower layer itself the product, an already-owned hard part, or a non-negotiable security/control boundary?
- Will it receive permanent ownership, on-call, benchmarks, and a roadmap through model and platform churn?
If the first answer is being outsourced or the second is no, buying creates lock-in at the differentiated layer. If the last two answers are no, building creates a permanent infrastructure tax.
Dogfooding Is the Whole Point
A tool you build but don't use is a portfolio piece. A tool you build and live inside is a multiplier. Each of Kevin's products is both shipped to others and used to build the next:
- Sigil builds the sites. The Dedalus website and the Agent Machines and Loop dashboards are built with Sigil's tokens, presets, and agent skills — instead of buying a component library and paying the "AItax" of generic output. The design system isn't bought; it's built once and then used to skin everything. Source: reticle-ui/README.md, 2026-06-13
- Agent Machines runs the fleet. Rather than renting a vertical agent-SaaS for each job (a code reviewer, a research bot, a news agent), Kevin builds the platform his persistent agents run on and provisions specialists from presets.
- Loop keeps the skills fresh. Instead of buying an automation product that needs babysitting, Loop is the operator desk that refreshes Kevin's own agent skills while he sleeps. Source: loop/README.md, 2026-06-13
- This wiki is the operating system. The knowledge base, automations, and skills that run Kevin's whole workflow are built, not subscribed to.
The pattern: build it, use it on real work immediately, let the use surface the bugs, and let each tool become a primitive for the next. Owned tools compound; rented tools give you parity and a recurring bill.
Why It Works Now
- Completeness is cheap. Boil the lake — the last 10% that made building uneconomical (tests, edge cases, polish) costs minutes with AI, so a self-built tool can actually reach production quality, not just demo quality.
- You can encode your taste. Constraints over context means a self-built system can carry your judgment as rails an agent follows, so "build it yourself" no longer means "and maintain it by hand forever" — the agent operates the thing you built.
- Ownership fuels the work. You pour everything into what's yours; a bought tool is someone else's baby. The motivation to make the tool excellent only exists when the tool is yours.
- Building teaches the base layer. Susan Zhang's "neolabs" critique is a caution about inherited infrastructure: teams that only compose on top of prestige-company scaffolding can miss the burden of making the lower layer exist. For Kevin, this does not mean rebuilding commodity primitives by reflex. It means personally building the differentiated layer often teaches constraints, failure modes, and taste that a bought surface hides. Source: X/@suchenzang, 2026-05-16
The Sell-Side Mirror
Build-don't-buy for yourself is the same coin as sell-the-outcome for everyone else. The tools Kevin builds to avoid buying SaaS are themselves shipped as public products (Sigil, Loop, Agent Machines are open source / live). What is undifferentiated commodity for the vendor you rent from is differentiated advantage for the builder who builds it — so the builder who builds for themselves often discovers the product worth selling. The decision to build instead of buy is also a decision about what you might one day sell.
The form this takes is Open Core. You don't have to choose between "build it yourself" and "sell it": open-source the framework so anyone can build and own it, and charge for the hosted, integrated, pre-configured version for everyone who'd rather not assemble it. Agent Machines is the example — an open-source persistent-agent framework (MIT) where you pay to spin up agent machines and persistent agents with integrations and configurations built in. The model mirror is Reflex: an open-source Python web framework ("you own everything you build") where you pay for the Cloud/Enterprise tier to deploy and get integrations like Snowflake wired in. The open framework is distribution and credibility; the hosted assembly is revenue. Source: User, 2026-06-15; reflex.dev/pricing, 2026-06-15
Anti-Patterns
- NIH everything. Rebuilding Postgres, auth, or a payment processor to "own the stack" burns the advantage AI gave you on plumbing with no taste payoff. The point is the line, not maximalism.
- Build and shelve. Shipping a tool you never dogfood. If you wouldn't use it on tomorrow's real work, you built a demo.
- Buy the differentiated layer. Outsourcing the one thing that should carry your point of view (your design language, your agent conventions) to a vendor's median defaults — the generic-output tax.
- Confusing "rent" with "give up." Renting commodity primitives is a multiplier, not surrender; search before building still applies — don't build what a one-line dependency already does well.
- Forgetting that good SaaS sells time back. Long Live Hard SaaS is why "build, don't buy" is not maximalism. If a vendor reliably absorbs bug discovery, maintenance, integrations, and operational risk for an undifferentiated surface, buying it is rational.
Internal utility and external demand
A tool that solves your own problem establishes internal utility; it does not by itself establish demand from other users. Before treating a dogfooded tool as a product to sell, test the intended user's problem and observe whether they adopt it. Manual recruitment and service can provide that evidence before more code does. Source: Paul Graham, Do Things that Don't Scale, July 2013
Dax's September 2026 warning about programmers becoming founders is a personal counter-signal about transferring technical confidence into unfamiliar domains. Keep its useful question—what evidence supports this nontechnical judgment?—without adopting its blanket claim about programmers. Graham's earlier account likewise cautions about startup instincts while explicitly preserving judgment about people and emphasizing knowledge of users. Source: X/@thdxr, 2026-09-07; Source: Paul Graham, Before the Startup, October 2014
Connections
| Connection | Implication |
|---|---|
| Builder Ethos | The Golden Age compression table is why the build/buy line moved; boil-the-lake is why self-built tools can hit production quality. |
| Ownership Drives Building | You only pour everything into tools that are yours — so owned tools get the obsession that makes them excellent. |
| Constraints over Context | Self-built systems can encode taste as rails an agent follows, so building no longer means hand-maintaining. |
| Services-as-Software | What you build to avoid buying is often what's worth selling — build-for-self and sell-the-outcome are mirrors. |
| No One-Off Work | Codifying recurring work into owned skills/automations is build-don't-buy applied to your own time. |
Timeline
- 2026-08-11 | Converted the agent-platform case into a layered rule: own portable context, policy, evaluations, and proof; rent replaceable execution; build lower layers only when they are product-defining, already owned, security-critical, and durably staffed. Registered this philosophy as a stable brain object so future sources can interrogate it rather than merely quote it. Source: X/@davep X Article, 2026-07-27; Stripe Minions; Sierra Pinecone and MCP Gateway; Cursor self-hosted Cloud Agents, reviewed 2026-08-11
- 2026-07-04 | Source-reviewed Susan Zhang's "neolabs" bookmark and added the inherited-infrastructure caveat: personally building the differentiated layer teaches lower-layer constraints that prestige scaffolding can hide. Source: X/@suchenzang, 2026-05-16
- 2026-06-15 | Extended the Sell-Side Mirror with the open-core form and linked it to Agent Machines: open-source the framework, charge for the hosted/integrated/configured product — mirror of Reflex (OSS Python framework + paid Cloud/Enterprise where Snowflake/Databricks integrations live). Source: User, 2026-06-15
- 2026-06-13 | Articulated by Kevin as a standalone belief: instead of buying SaaS the way people have for decades, use the products he builds (Sigil UI, Agent Machines, Loop) to build everything else. Filed as a philosophy; cross-linked to the Golden Age (builder-ethos), ownership, constraints-over-context, and the services-as-software sell-side mirror. Source: User, 2026-06-13
- 2026-06-22 | Added the hard-SaaS counterweight: buying maintained SaaS is rational when the vendor is absorbing product-time, bug-finding, and integration burden for a commodity surface. Source: raw/notes/saas-bug-moat-slack-thread-2026-06-22.md