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.

There are six ways to work with AI across a build. This idea's AI moves are noted above. See Working with AI for all six and where each fits.

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 authentication because it is not where value lives. We weighed a managed service (Clerk), an open-source library (Lucia) and the platform's own primitive, then chose Clerk to protect the deadline. Build the context-shaped search 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.

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/shape-build-launch/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.

Common questions

1. The AI keeps asking me about Python, Node and APIs. Which do I pick?
   None yet. That is an engineering question and you are still on a strategy one. Decide what actually needs building before you pick how to build it. That is the whole story of The AI answered like an engineer.
2. Should I just build it myself to save the subscription?
   Only if that part is where your value lives. Price is the smallest cost, because owning a tool means maintaining it forever. Ask what you are really paying for in Don't Reinvent the Wheel.
3. How do I tell which part is worth building?
   Build the one piece that makes the result yours. If nobody would notice you built the rest, buy it.
4. I am building fast with AI. Isn't that progress?
   Not on its own. Building the wrong thing quickly is rework with a pretty commit history. Decide what is worth building first, the point of AI did the easy part.
5. Isn't building everything myself more flexible?
   Flexibility you never use is just cost. Buy the standard parts so your effort goes where it sets you apart.
6. Is open source or a framework buying or building?
   Buying. Buy means acquire, not pay. A framework you install from a public package registry even hands you judgment, the decisions already made and tested, so you write less and inherit more. It still carries a cost in maintenance and adaptation, that cost is just not on an invoice. See Don't Reinvent the Wheel.
7. Where does this land if I need a website and a newsletter?
   It is the clearest buy decision you will make. Publishing, membership and email are solved. Ghost solves them on open foundations you can leave with. Building your own is spending your one advantage on a problem somebody else already finished. That is the whole argument for Your Ghost site.
8. And if I am building a product, what should I refuse to build?
   Sign-in, payments and the rest of the plumbing. Buy those, then spend everything you have on the one part that is actually yours. Build your product is built that way on purpose. Ghost and the Cloudflare Workers stack together covers the case where you need both.

What now?

Apply it. Guide me turns what you are building into a prompt that walks you through this idea.

Get all 27. The guide is a free coffee-length read with the whole method. Join free and it is yours to download.

Get a hand. Work with me and we will work out together what is worth doing. The first conversation is free.