Build, Buy, Borrow, Fake, or Defer

Every Capability Sends an Invoice

The architecture in the previous chapter followed one agency report from upload to delivery. On paper, the system was modest: an agency account, a campaign export, a draft explanation, a review step, and an email. Yet even this narrow promise requires identity, storage, parsing, domain rules, model access, approval, delivery, permissions, error handling, and support.

The founder could build all of them. That is precisely the danger.

A first implementation may take an afternoon; ownership has no such limit. Code returns as edge cases, tests, upgrades, support questions, migrations, security work, and customer expectations. A capability that once looked like a task becomes a standing claim on the founder’s attention.

Before product-market fit, the useful question is not “Can I implement this?” It is:

What is the least ownership I can accept while still learning the truth and keeping the customer promise?

That question has five possible answers: build, buy, borrow, fake, or defer. The answer belongs to a capability, not to an entire feature, and it lasts only until the evidence changes.

Split the Promise Before Choosing

“Build a client portal” is too large to decide. The label hides account identity, agency ownership, file upload, comments, notifications, permissions, billing state, audit history, and a dashboard. Those capabilities do not deserve the same form of ownership.

Return to the agency-reporting pilot. Its promise is exact: upload one supported campaign export and receive a reviewed, client-ready explanation of important changes. Break that promise along the path the customer’s work takes:

1. identify the agency operator;
2. accept and retain the original export;
3. parse campaign facts;
4. decide which changes matter;
5. draft an explanation;
6. let the founder inspect and correct it;
7. deliver the approved report;
8. preserve enough state to investigate a failure.

Now each decision can expose its reason. Does this capability create the product’s value, or merely enable it? Does the next product test require it? Could one person perform it manually without misleading the customer? Is there a mature service or a bounded piece of maintained code? If it fails, is the result inconvenience, corrupted evidence, financial harm, or broken trust? What customer truth would be difficult to recover if the choice changed?

These questions are a route through the decision, not an algorithm. Risk can override convenience. A managed identity service may be the safest choice for authentication while the product still must build its own account-ownership rules. “Trust boundary” does not automatically mean “write the infrastructure yourself.” It means the founder remains responsible for the promise at that boundary.

Buy the Machinery; Build the Meaning

Start with identity. Login is necessary, but it does not explain why an agency would pay for a weekly report. A mature authentication service or framework can own password handling, sessions, and recovery. The product must still own the mapping from that identity to an agency, its clients, and the reports the operator may see. Buying authentication removes commodity work; it does not remove authorization design.

Email has a similar seam. The founder can buy delivery, bounce handling, and provider logs while building the report content, approval state, recipient rules, and delivery history. If the provider fails, the product should still know which version was approved and whether the customer received it.

Buying is strongest when the capability is well understood, offered through a clear boundary, and not itself the product’s claim. Hosting, databases, object storage, payments, transactional email, error tracking, analytics, support inboxes, scheduling, and customer-relationship tools often begin here.

The vendor still sends an invoice in money and dependence. Before adopting one, the founder should be able to answer:

• Which product records and vocabulary remain ours?
• Can we export the customer state that matters in a usable form?
• What does the customer experience during an outage?
• Which change in price, volume, privacy needs, or product behavior would force a move?

Do not build a universal abstraction around every vendor. That merely pays for an imagined migration in advance. Protect the durable product model, record provider identifiers at the edge, and create a narrow boundary where an outage or replacement would otherwise corrupt customer truth.

Borrow a Part, Not Someone Else’s Product

The campaign export contains dates, numbers, identifiers, and a documented file format. A maintained parser or date library may remove weeks of ordinary work. The product’s interpretation of a meaningful campaign change should remain its own.

That is the useful scale of borrowing: a bounded problem whose code the founder can understand, test, upgrade, and replace. A PDF renderer, chart library, file-format parser, API client, or validation component can accelerate the product without deciding what the product is.

A full starter application is more dangerous. It may quietly decide that every customer has a team, every team has roles, every account has a subscription, and every subscription maps to one of its plans. Week-one speed then becomes month-three resistance.

Before borrowing, inspect maintenance, scope, architectural fit, license, and exit. If the founder cannot debug the component under pressure or explain what assumptions arrived with it, the code is not leverage yet.

Fake the Machinery, Never the Truth

The first report does not need a fully automated intelligence pipeline. A model or rule set can produce a draft, and the founder can review every explanation before delivery. Corrections reveal which judgments repeat, which inputs are missing, and what agencies consider client-ready. Manual work is doing research that code would otherwise conceal.

This is a legitimate fake because the customer still receives the promised reviewed report. The manual step becomes unethical when the customer’s decision depends on believing it is absent. Never conceal human handling that materially changes privacy, security, compliance, speed, price, or reliability. Do not fake financial, medical, legal, security, or safety-critical judgment.

Three conditions keep manual delivery honest:

• Consent: the customer would still participate if the manual involvement were clear.
• Risk: the manual path does not create exposure beyond the stated promise.
• Learning: the work records patterns that can change the product decision.

Manual work also needs a capacity limit. Five reviewed reports may reveal the workflow. Fifty individually crafted reports may reveal only that the founder has built a service business behind a login screen. The limit should be chosen before enthusiasm turns custom labor into an invisible product requirement.

Defer Until Evidence Pulls the Work Forward

The pilot can deliver a valuable weekly report without direct advertising-platform integrations, white-label themes, a client portal, elaborate team roles, or usage-based billing. None of those capabilities is inherently frivolous. They simply answer questions the current test has not asked.

Deferral becomes a real decision when it includes a trigger. “Later” protects nothing. These triggers do:

• Add the first direct integration when retained agencies identify repeated CSV handling as the obstacle to continued use.
• Add multiple agency roles when real users need different permissions inside one account.
• Add client access when agencies are already forwarding reports and need a trustworthy shared history.
• Automate a manual correction when the same rule recurs often enough to specify and test.
• Reconsider the delivery provider when measured cost, reliability, privacy, or latency threatens the promise.

A trigger should describe observable pressure in the product. Calendar dates, competitor pages, and founder restlessness are poor substitutes. Deferral is safe only while it leaves value and trust intact; backups, access boundaries, payment integrity, and honest data handling cannot be postponed when the promise already depends on them.

Build the Narrow Irreducible Slice

After the other choices, the agency pilot still needs original product code. The agency-and-client model expresses who owns the work. Change-detection rules express the product’s judgment. The review screen makes accuracy inspectable. Report versions preserve what was approved and sent. Those capabilities create value, produce differentiated learning, or protect product-specific trust.

Even here, “build” is not permission to build the imagined company. The importer can support one export format. The rules can cover the few change types agencies already care about. The review screen can serve one founder operator. The first permissions model can represent an agency owner without anticipating every future collaborator.

Build candidates usually fall into a small set: the core workflow, a differentiated interaction, the product’s domain model and rules, a product-specific evaluation or review loop, unique coordination, and the ownership boundaries that keep customer work safe. The test is not whether the capability sounds central. The test is whether a lower-ownership choice would prevent the product from delivering value, learning the riskiest fact, or keeping its promise.

The Capability Matrix

Use the five choices as different cost shapes, not as permanent labels.

For the reporting pilot, the initial record might be: buy authentication and email delivery; borrow bounded parsing components; fake final quality control through disclosed founder review; defer live integrations and client access; build the account model, change judgment, review flow, and report history. This is not a verdict on the mature product. It is the smallest responsible ownership plan for the next evidence cycle.

Decisions Expire

After five agencies complete several weekly cycles, the record should be opened again. Perhaps founder corrections cluster around three recognizable campaign patterns. Those patterns can now move from fake to build because the product has evidence for the rule and examples for its tests. Perhaps agencies value the report but repeatedly fail at CSV export. The first direct integration may move from defer to build or buy. Perhaps the drafting provider’s price rises while its output still requires heavy correction. A different provider, borrowed model, or narrower rule-based draft may become the better choice.

The number of customers is not the trigger by itself. The trigger is the observed change in value, friction, risk, or economics. “At fifty accounts, build billing” is weak. “Move from manual invoices when reconciliation delays access or consumes more founder time than the provider integration” names the pressure and the reason.

Record meaningful decisions in a few lines:

• Capability: the behavior or operating function under consideration.
• Next product test: what must be learned or delivered now.
• Choice and reason: build, buy, borrow, fake, or defer, tied to present evidence.
• Risk accepted: maintenance, vendor exposure, borrowed assumptions, manual burden, or remaining friction.
• Boundary or exit: the customer state that must survive a change.
• Revisit trigger: the observable event that reopens the decision.

This is enough history to keep a customer request, a clever template, or an easy code generation session from silently becoming permanent product scope.

Before the next commit, list the capabilities it introduces. For each one marked build, explain why buying, borrowing, honest manual work, or waiting would weaken the next test or the customer promise. For every other choice, write the trigger that would change it.

The aim is not to avoid code. It is to reserve code for the part of the product that must carry its full weight. Once those boundaries are chosen, the remaining question is whether the small system is responsible enough for real users. That is the work of the technical baseline.