Build-Buy-Borrow-Fake-Defer Matrix

Decide the Capability, Not the Feature

A founder planning a client portal may think the choice is build or buy. “Portal” is too large to decide. It contains identity, file exchange, comments, notifications, permissions, billing state, and a customer-visible history. Some of those capabilities may deserve product code. Some may belong to a service, a maintained library, a manual workflow, or nowhere in the current product.

Use this artifact when a capability is about to consume engineering time, vendor spend, manual labor, or customer trust. The aim is not to minimize code at any cost. It is to accept the least ownership that can deliver the current promise and answer the next important product question.

Write one record per capability. A decision that covers “the backend,” “analytics,” or “the onboarding system” is still hiding several decisions.

Begin with the decision window:

Customer promise in this window:
Next product question:
Capability under consideration:
Who needs it, and what must they be able to do?
Evidence that this need exists now:
Consequence if the capability is absent or fails:
Decision deadline:

The window may be one experiment, three paid pilots, or the next month of operation. It should end when the evidence can change, not on an arbitrary roadmap date.

Five Ways to Carry the Work

Each choice accepts a different kind of burden.

Build means writing and owning the narrow product-specific behavior. Choose it when the capability expresses differentiated value, produces essential learning, or enforces a trust rule that the product itself must understand. The cost includes tests, maintenance, migrations, security, support, and future compatibility—not only the first implementation.

Buy means depending on a service for a well-understood capability behind a boundary you can operate. The service may own password handling, payment processing, email delivery, storage, or monitoring; the product still owns its customer promise. Record the data sent, the state that remains authoritative in your system, how failure becomes visible, and how you would retrieve essential customer records.

Borrow means adopting maintained code for a bounded problem: a file parser, API client, renderer, validation library, or similar component. You accept its license, assumptions, upgrades, and debugging. Borrow only what you can test at the boundary and replace without rebuilding the product around someone else’s worldview.

Fake means delivering the real promised outcome with disclosed or ethically immaterial manual work while automation remains uncertain. The customer must not be misled about human involvement that affects privacy, security, compliance, price, speed, or reliability. Set a capacity limit and record what the manual work is meant to teach; otherwise a useful experiment quietly becomes an exhausting service.

Defer means the current promise and the next test do not require the capability. Deferral is an active choice only when it names the friction being tolerated and the observable trigger that will reopen the question. “Later” is a wish, not a boundary.

Route the Capability

Work through these questions in order. Stop when a choice survives the risk check.

1. Does the current promise or next product question require this capability? If not, defer it. Name the remaining friction and the event that would make the capability necessary.
2. Can the outcome be delivered manually, honestly, and safely? If so, fake the machinery for a bounded number of customers or operations. Define consent, handling rules, capacity, and the learning you will capture.
3. Is this a commodity capability with a service you can trust and contain? If so, buy it. Keep product meaning and authoritative customer state on your side of the boundary.
4. Does maintained, understandable code solve a bounded part of the problem? If so, borrow it. Check license, maintenance, fit, testability, and the replacement path.
5. Would every lower-ownership choice weaken the promised value, the necessary learning, or product-specific trust? Build only that irreducible slice.

Risk may end the route early. Real users require appropriate access control, data handling, recovery, payment integrity, and safety whether the product has one customer or one thousand. A manual path that exposes sensitive data is not made acceptable by calling it an experiment. Buying a managed service can reduce implementation work, but it cannot transfer responsibility for how the product uses it.

Record the Decision and Its Exit

Complete this after investigating the plausible choices. Use observed facts where they exist and label assumptions plainly.

Capability:
Decision window:
Customer promise or product question served:

Evidence available now:
Unknown that matters most:
Options considered:

Choice — build, buy, borrow, fake, or defer:
Why this carries the least responsible ownership now:
Narrow scope of the choice:

Customer data or state involved:
Failure the customer could experience:
How failure becomes visible:
Founder repair or fallback:

Burden accepted — maintenance, vendor dependence, borrowed assumptions,
manual labor, or remaining friction:
Capacity or cost boundary:
State that must survive replacement:

Observable revisit trigger:
Next action and owner:
Decision date:

A calendar review can prevent neglect, but it is not sufficient by itself. Prefer a trigger tied to behavior: repeated manual corrections become specifiable, export friction blocks retained users, vendor cost breaks the product economics, an outage threatens the delivery promise, or a deferred capability begins to obstruct activation.

Worked Decision: Report Review

Suppose three paid pilot customers upload campaign exports and receive a reviewed report within one business day. The founder is deciding how to provide final quality control.

Fully automated approval would be fast, but the founder does not yet know which explanations customers consider safe to send to their clients. Buying another model does not answer that product question. Borrowing a generic evaluation library cannot encode a judgment that has not been learned. Deferring review would weaken the explicit promise.

The founder chooses fake: every generated draft receives a human review before delivery. The choice is limited to three pilots and no more than fifteen reports per week. The review log records the draft, correction category, final text, time spent, and whether the agency accepts or revises the report. Customers are told that reports are reviewed; access to their exports follows the stated data-handling promise.

The accepted burden is founder time and possible inconsistency. A report cannot be marked delivered until the review is recorded, so provider success cannot masquerade as customer success. The decision reopens when correction patterns repeat well enough to specify and test, or when review volume exceeds the weekly limit. At that point the repeated rules may move to build, while uncommon judgments remain manual.

Notice what the record prevents. “Use AI for reports” no longer hides product judgment, and “automate later” no longer hides a service business. The choice has a scope, an honest operating path, evidence to collect, and an exit.

A Decision Is Ready When It Can Expire

Before acting, make sure a skeptical reader can identify the capability, the present evidence, the burden you accepted, the customer state you must protect, and the event that changes the choice. If you cannot name those things, the missing work is not another row in a matrix. It is the smallest investigation that would make the decision real.