The Build-vs-Buy Questions
Before "should we build payments ourselves?" can be answered, five questions have to be: is this our core differentiation, can a provider solve it, what does integrating cost, what does operating it cost, and what happens when the provider fails. The answers are the decision; the slogan is not.
The situation, the reflex, and why it stalls
Every lesson starts where being stuck starts: someone has a problem, and the first move that comes to mind feels like progress.
A capability the store needs — payments, email, search, image storage — could be built or bought. What do you ask before deciding, and why is "it would be faster to use a service" not yet an answer?
Checkout needs to take money. One voice says "just use a payment provider, everyone does"; another says "we should own our payment flow, it is the heart of the business". Both sound reasonable, and you notice that neither has said anything specific about *this* store.
Decide by temperament. Engineers who like building see a service as a black box that will constrain them; engineers who like shipping see building as a distraction from the product. Either way the decision arrives before the questions, and it feels principled because it is consistent.
The decision is made for the whole category at once — "we buy infrastructure, we build product" — and the category boundary is wherever it needs to be to justify what was already decided. Search is "product" when someone wants to build it and "infrastructure" when they do not.
- The decision is made for the whole category at once — "we buy infrastructure, we build product" — and the category boundary is wherever it needs to be to justify what was already decided. Search is "product" when someone wants to build it and "infrastructure" when they do not.
- Neither temperament has costed the integration. "Use a provider" is said as though integration were free; in the store it is a redirect, a confirmation handler, a pending state, a duplicate check and a public URL, none of which the provider writes for you.
- Neither has costed operation. Building your own email sender is a week; running it is forever — deliverability, bounces, a blocked IP the week of a launch. The build estimate covered the week.
- Neither has asked what happens when the bought thing fails, so the store's first outage is the provider's outage, and the design has no opinion about it because the decision never considered it.
The move
Precisely enough to apply it to a problem you have never seen — not a slogan.
- Refuse the category answer and ask five questions of *this* capability, in this system, for this team. Is it core differentiation — the reason a customer chooses this store over another? Can a provider actually solve it, including the awkward parts — refunds, disputes, the tax line — or only the demo? What does integrating cost — not the SDK call, but the states, handlers and failure paths the integration forces into your design? What does operating it cost — the fee, and the operational load of the built alternative? And what happens to the store when the provider fails, is slow, changes its API or rate-limits you?
- Answer each with a fact about the store, not a belief about the category. "Payment is not why customers choose us; a provider handles refunds and disputes, which we could not; integration is a redirect and a webhook, which the spike measured; the fee is a fraction of each order; on provider failure the order sits pending and we tell the customer" — that is a decision with reasons.
- Then decide, and write the reasons next to the decision with the condition under which it would flip (The Decision Journal). Build-vs-buy is one of the more reversible-looking decisions that turns out not to be: two years of orders in a provider's data model is a cost of leaving that the original decision should have priced (Reversible vs Irreversible Decisions).
Five questions, three capabilities
The reflex answers once for the category. The move answers five times per capability, and the matrix shows why that matters: three capabilities in the same store, the same five questions, and three different decisions. The search row is the interesting one — the answer depends on what the founder says the store *is*.
| Payment | Search | ||
|---|---|---|---|
| Core differentiation? | No — no customer chooses a store for its card form | No | No for "filter by name"; yes if the pitch is "finds the right part" |
| Provider solves it? | Yes, including refunds and disputes we could not | Yes, including deliverability we would fight forever | Retrieval yes; the ranking that differentiates, no |
| Integration cost | Redirect, webhook, pending state, duplicate check, public URL | One call per order event, templates | An index to keep in sync with products; a query layer |
| Operating cost | A fee per order; built alternative: compliance, unpayable | Near zero; built alternative: reputation, bounces, blocked IPs | An index to run or rent; built alternative: a database query, free |
| When it fails | Orders pending; customer told; nothing lost | Confirmation late; order must not depend on it | Fall back to the database filter, degraded but working |
| Decision | Buy; flip if fees exceed a payments team | Buy; design so nothing waits on it | V1: neither, a query. Later: buy the index, build the ranking |
The decision, as a decision
A decision device with named options and no winner. The options are the same for every capability; the when column is what the five questions fill in, and it is different each time. Read the cost column as the thing the temperament reflex leaves out.
How should the store meet this requirement?
when Not differentiating; a mature provider solves the whole requirement including the awkward cases; integration is a known shape; the failure mode is one the design can absorb.
cost A per-use fee forever; integration states and handlers you own anyway; a dependency that can be down, slow, changed or rate-limited without you; data that makes leaving expensive.
when It is the differentiation, or no provider solves the requirement completely, or the operating cost of the built version is genuinely small — a database query, a cron job.
cost The build estimate, which is the small part; then operation at month six — the on-call, the edge cases, the deliverability fight — which the estimate did not include.
when The requirement in V1 is met by something already in the system: "search" is a WHERE clause, "email" is a log line, "image storage" is a folder.
cost A later migration to the real thing, which is cheap if the boundary was drawn and expensive if the folder path is in forty places.
when A provider solves the generic part and the differentiation lives in a layer above it — buy the index, build the ranking; buy the model, build the evaluation.
cost Two integrations instead of one, and a boundary that has to be designed deliberately or the provider's shape leaks into the part you meant to own.
1capability: card payments + refunds2core? no (founder, asked cold)3provider? yes, incl. disputes we cannot do4integration: redirect, webhook, pending state, dedupe, public URL (~days)5operating: % per order vs compliance we cannot pay6failure: order pending; customer told; nothing lost7decision: BUY8flips if: fee > cost of a payments team, or provider drops our market9leaving cost: saved cards + dispute history live with themNine lines. The last two are the ones a temperament decision never writes, and the ones the team will need in two years.
What "just use a service" hides
The buy reflex is right more often than the build reflex, and it is still a reflex. The pipeline below is what integrating the payment provider actually involved in the store — every step is work the provider did not do, and every one was invisible in "just use a provider".
- 1Pending order
The order must exist before the redirect, in a state that means "not paid yet".
fails by Skipping it: the customer returns and there is nothing to show them.
- 2Redirect
Send the customer to the provider's page with the order reference.
fails by Losing the reference: the confirmation cannot be matched to an order.
- 3Confirmation handler
Receive the provider's message, verify it is genuinely theirs, mark the order paid once.
fails by No verification: anyone can mark an order paid. No dedupe: paid twice.
- 4Return page
Show the customer a truthful state: pending, paid, or failed — not "success" because they came back.
fails by Promising paid before the confirmation arrives.
- 5Public URL
The handler has to be reachable by the provider, which means a deployed environment before payment can be tested.
fails by Testing only on a laptop: webhooks never arrive.
- 6Reconciliation
A way to ask the provider "what happened to this charge?" when the confirmation never came.
fails by Orders stuck pending forever with money taken.
Six steps, all yours. Buying removed card handling, compliance and disputes — enormous — and left this. The five questions price it; the slogan does not.
How to do it
Most important first.
- Write the capability as a requirement first — "the store must take card payments and issue refunds" — not as a component. A requirement can be met by building or buying; a component has already decided (Goal vs Implementation).
- Ask the differentiation question of the founder, not of yourself. "Would a customer choose us because of how payment works?" usually gets an immediate no; "because of how search works?" sometimes gets a yes, and that is the interesting case (Core Differentiation).
- Check whether the provider solves the *whole* requirement by listing the awkward cases and finding each in its documentation: refunds, partial refunds, disputes, currency, the failed-then-succeeded charge (Guarantees and Failure Modes).
- Cost integration by sketching the states and handlers it forces into your design, and cost operation by asking what the built version needs at month six, not week one (Integration and Operating Cost).
- Write the failure paragraph before deciding: what the store does when the provider is down, and whether that is acceptable (When the Provider Fails).
Worked on a concrete problem
The move has to produce something. This is what it produced.
- Payment, for the store: not differentiation — no customer picks a store for its card form. A provider solves the whole thing including disputes, which the team could not solve at all. Integration: a redirect, a confirmation webhook, a pending order state and a duplicate check, measured by the spike at a few days. Operating: a percentage of each order, versus the built alternative's compliance burden, which is not a cost the team can pay. Failure: orders sit pending, the customer is told, nothing is lost. Decision: buy, with the flip condition "if transaction volume ever makes the fee larger than a payments team, revisit".
- Email, for the store: not differentiation. A provider solves delivery, bounces and reputation. Integration: one API call per order event and a template. Operating: nearly nothing bought; a great deal built, because deliverability is a continuous fight. Failure: a confirmation email arrives late or not at all, which the order page must not depend on. Decision: buy, and design so the store never waits on the email.
- Search, for the store: "filter products by name" in V1 is not differentiation and a database query solves it — neither build nor buy, just a
WHERE. If the founder's pitch is "the store that finds the right part for your car", search *is* the differentiation, a generic provider solves the retrieval and not the ranking that matters, and the decision splits: buy the index, build the ranking. The five questions produced three different answers for three capabilities in one store. - The AI assistant over company documentation: the model is bought — nobody in the team differentiates by training one. The retrieval and the evaluation of answers against the documents are where the assistant is good or bad, so those are built. The question "can a provider solve it?" was answered "yes for generation, no for knowing whether the answer was right".
How you know it worked
What now exists that did not before, and what question you can now ask.
- The decision has five written answers next to it, each a fact about this system, and a condition under which it flips.
- Different capabilities in the same system got different answers, which means the questions were asked rather than the category applied.
- The integration cost is a list of states and handlers, not the word "SDK".
- There is a sentence describing the store during a provider outage, written before the provider was chosen.
The questions you can now ask
The field this whole domain exists for. After this lesson, these are the questions to put to an unfamiliar problem.
- ?Is this capability why a customer would choose us — or is it something every competitor has and nobody notices?
- ?Does a provider solve the whole requirement, including the awkward cases, or only the demo?
- ?What states, handlers and failure paths does integrating this force into my design?
- ?What does the built version cost to *operate* at month six, and who pays it?
- ?What does the system do while the provider is down, and is that acceptable?
- ?What would have to change for this decision to flip, and what would leaving cost by then?
What can go wrong
- The five questions become a form filled in to justify the temperament. "Is it core?" answered "yes" for everything the team wants to build. The test is whether the founder, asked the differentiation question cold, gives the same answer.
- The questions are asked once, for every capability, before any of them is understood. Build-vs-buy for search is not decidable until search is a requirement with a shape; asking early produces a decision that will be remade.
- The reversibility of "buy" is overestimated. The integration can be replaced; the data in the provider, the customer records, the saved payment methods often cannot. The cost of leaving belongs in the decision.
- The move is applied to a library. Build-vs-buy is about a *dependency with an operator on the other end* — someone who can go down, change terms or rate-limit you. Choosing a date-formatting library is a different, smaller question (Evaluating a Technology).
- Five questions per capability is slower than a category rule, and for the clear cases — nobody builds their own card processing — the questions confirm what everyone knew.
- Answering "not core" honestly means telling an engineer that the thing they wanted to build is not the point of the company. That conversation is part of the cost.
- Writing the flip condition commits you to noticing when it arrives, and most teams do not have a mechanism for re-reading old decisions.
- "So the answer is usually buy." The answer is usually *buy for non-differentiating capabilities with mature providers*, and the store has several. The slogan "never build what you can buy" is falsifiable and false: a capability that is the differentiation, or one no provider solves completely, is built even though it could be bought.
- "Core means important." Payment is essential and not core. Core means *the reason customers choose us* — differentiation — and essential capabilities that are not differentiating are the strongest candidates for buying, because they must work and someone else has already made them work.
- "Build-vs-buy is a technology decision." It is a product decision with a technology consequence. The differentiation question can only be answered by whoever owns the product, which is why the founder is in the room.
Where this applies
Problem-solving advice is stated as universal far more often than it is. These labels say what each method is specific to — and where CONTESTED appears, the note gives the strongest form of the opposing view.
- GENERALThe five questions apply to any capability with a provider on the other end — payments, email, search, storage, models, authentication — in any system; what changes between systems is the answers, and the point is that the answers change.
- DOMAIN-SPECIFICFor a store, payment is bought almost without exception because the compliance burden of building it is not a cost a small team can pay; for a payments company, the same capability is the entire product and the question inverts. The lesson's answers are the store's, not the category's.
- ILLUSTRATIVEThe store, the founder, the spike's "few days" and the car-parts pitch are invented to show the five questions producing different answers for different capabilities; no real provider or fee is described.
Where the depth lives
This domain asks the question and hands the answer off by name.