Why does Build vs. Buy matter?
A startup's scarcest resource is engineering time, and every week spent rebuilding something that already exists is a week not spent on what makes the company different. The usual rule is to build what is core to your advantage and buy everything else: authentication, payments, email delivery, and analytics are solved problems for most companies. The rule bends when an off-the-shelf tool cannot do what your product needs, when its price grows faster than your revenue, or when depending on a vendor creates a risk you cannot accept.
What does Build vs. Buy look like in practice?
Suppose an early team estimates that building its own payments system would take two engineers about three months, against a payment provider that charges a few percent per transaction and takes a week to integrate. At current volume the provider's fees are a small fraction of what six engineer-months cost, so buying is clearly right. The decision is worth revisiting only if volume grows large enough that the fees become a material share of revenue, and even then the comparison has to include the ongoing cost of maintaining what you build.
What are the common mistakes with Build vs. Buy?
- Comparing a vendor's price against the cost of building it once, and ignoring the cost of maintaining it forever.
- Building infrastructure because it is interesting rather than because it is an advantage.
- Buying a tool for a capability that is the product's core differentiator, which hands the advantage to a vendor.
- Never revisiting the decision as scale, prices, and needs change.
Related concepts
- Product Requirements Document (PRD)A short written brief that says what a feature or product must do, for whom, and how you will know it worked, before anyone starts building it.
- Vendor ManagementKeeping track of the suppliers and subscriptions a company accumulates: what each costs, when it renews, who owns it, and what leaves with it if you stop.
- Technical DebtThe accumulated cost of past shortcuts in how the product was built, code that works today but makes every future change slower, riskier, or more expensive than it would be if built properly.
- Competitive MoatA structural reason your advantage survives a well-funded competitor deciding to copy you.