2.2.2 - Buy vs Build Is a Strategy Choice, Not an Engineering One

Buy versus build decision

Is this buy-vs-build choice improving the first user outcome?

The call

Buy means acquire, not pay. Build is what you write, buy is everything you don't. Make the call on where value lives, or AI helps you build what should have been acquired and rebuild what already works.

Sharpen the buy versus build decision with AI

This is a Build idea, so there are two AI moves: first Sharpen the buy versus build decision using the prompt below, then Build it with AI, vibeCoding the thinnest working code that tests the decision. This idea also calls for Set AI up to help.

New here? Let your AI do this with you. Paste your problem into Guide me and it builds a prompt that walks you through this in ChatGPT or Claude. You do not need to know how to prompt.

Prefer to drive the AI yourself? Give ChatGPT or Claude this page and ask it to help. For skill.txt, the Claude Code plugin and other ways in, see how to use vibe2value.

Or copy this prompt into AI chat, replace the bracketed lines with your real buy versus build decision and keep the instruction exactly as visible here. It helps you put your build/buy-vs-build.md together by refining your three lines until two people would make the same product decision from them.

Buying or building changes what you actually construct, so it sits with the decisions about how the build goes together. That is Ways to build it with AI, one of the six ways to work with AI.

The same idea on a recipe card

A smart cook does not make everything from scratch. You buy the puff pastry and the stock, then pour your real effort into the filling that makes the pie yours. Milling your own flour to save a few pence is effort spent where no guest will ever taste the difference.

Buy versus build is that same call. Buy the standard parts that are good enough off the shelf and build only where your effort actually shows up for the user. Decide it on where the value lives and not on what is fun to make, the way a cook spends their time on the filling and not on the flour.

The recipe card is just a simple example, using everyday cooking ideas everyone understands, to make the concept clear. See the recipe card.

What it really means

Buy versus build is not a tooling preference and buy does not mean paying a vendor. Build is the code you write yourself. Buy is everything you could acquire instead: a managed service, a platform primitive, an open-source library, a framework you install from a public package registry. It is a strategy call about where your effort creates advantage and where it does not. Until you can name one decision area, one reason to buy or build and one constraint that decides it, the discussion will loop. AI can help compare the options, but it cannot choose your leverage point.

Two things make acquiring the strong default in AI-assisted building. A framework is bought judgment: you inherit decisions already made and tested, not just code. And you do not resend the tokens on what already works, so your build effort goes to the part that is actually yours.

Acquired is not free. Open source and frameworks carry no invoice and still carry a cost: you own the patching, the maintenance and the adaptation, and you inherit a framework's opinions whether they fit or not. Weigh that cost like any other, it is just paid in time rather than on a bill.

Make the buy versus build decision concrete

Compare the broad version with a version you can actually test.

• Too vague: We should decide whether to use an existing service or build it ourselves.
• Concrete enough to test: Acquire inbound email and delivery because it is not where value lives. We weighed a managed mail service, an open-source relay and the platform's own primitive, then chose the managed one to protect the deadline. Build the policy because that is where the product makes a unique decision for the user.

The second version lets two people choose the same leverage point from it.

Both versions come from consideredContent, the one project carried through all 35 ideas. See the project.

Check the buy versus build decision

• Pass: You can say what the decision is about, why one side wins and which constraint makes the call.
• Fail: If the discussion still lives at the level of flexibility or control in general, it is not specific enough yet.

Do not move into vendor selection or implementation work until this passes.

What you'll walk away with

This post is about the framing decision: the words that pin down what this idea actually means for your build, before any code. You'll come out with your own knowledge-base/build/buy-vs-build.md written and sharpened: the buy versus build decision pinned down as a decision, three worked examples to map against your own surface and an AI prompt that pressure-tests it until two people would make the same call.

Write it down

Your buy-vs-build.md is a real file in your project. The AI forgets everything between sessions. It reads this file each time to pick up what you already decided, on this idea or another part of the build. Write it down once instead of explaining it again.

knowledge-base/framework/build/buy-vs-build.md is just a suggested name and place for this information. The name and the location are just how we organise this type of documentation, not something you have to follow. Call the file and put it wherever suits your project. What matters is that it is written down in a format that is easily understood by both people and the AI.

The .md ending is markdown, a plain text format often used for documents kept in a code repository like GitHub. It is just the common way people store this kind of writing alongside their code.

Writing it down is how you keep good context for your AI. See Keep the signal, not the noise for why this matters across a whole build.

Risk and mitigation

• Risk: Treating buy vs build as a technical argument and missing the user outcome, which leads to slow delivery and avoidable complexity.
• Mitigation: Define one user-impact metric first and use it to score both options before deciding.

Key takeaway

Do not move forward until you can say what the decision is about, why one side wins and which constraint makes the call.

How to document your buy versus build decision

Write your buy versus build decision up in full so your AI has the whole picture: the answer, why you believe it, what you are optimising for, where you might be wrong and the standing instruction it should follow. Keep it in a file with your project like this.

# Buy versus build decision

## Answer
Decision area: [what the decision is about]
Why buy or build: [why one side wins]
Deciding constraint: [which constraint makes the call]

## Evidence
Why you believe this. Conversations, examples, tickets, your own experience.

## Decision
What you are optimising for and what you are saying no to.

## Risk
Where you might be wrong and what would tell you.

## AI instruction
The standing note your AI reads on this project.

Here is one filled in so you can see what good looks like, grounded in the recipe card idea from earlier.

## Answer
Decision area: The puff pastry and the stock
Why buy or build: Buy them, they are good enough off the shelf
Deciding constraint: Put your effort into the filling that makes the pie yours

## Evidence
The shop puff pastry and stock have tested as good as my homemade ones, and making them ate hours I needed for the filling.

## Decision
Optimising effort into the filling that makes the pie mine. Saying no to making pastry and stock from scratch.

## Risk
A weak pastry or stock could let the pie down. Buy good ones and taste them before committing.

## AI instruction
Buy the puff pastry and the stock, they are good enough off the shelf. Spend the saved effort on the filling, which is what makes this pie ours.