Build vs Buy · Product Fluency

Build vs Buy · 3 min

Situation

“We can build that in two weeks.”

A team needs email delivery for product notifications. An engineer estimates two weeks for an initial sending service. A vendor charges a monthly fee.

Comparing the initial build with the subscription misses deliverability, retries, monitoring, abuse handling, maintenance, and future changes. Ownership continues after launch.

Mental model

Compare whole-system costs.

Consider time to value, strategic differentiation, integration effort, operating cost, reliability needs, vendor risk, and switching cost.

A commodity capability often favors buying. A capability that makes your product meaningfully different may deserve ownership. Neither statement is absolute: constraints can reverse the decision.

Example

Buy delivery; own the customer experience.

A product might use an email provider while keeping notification preferences, message rules, templates, and user-facing delivery states in its own system.

That boundary lets the team focus on product behavior. A clear internal interface and exportable records can make a future vendor switch less disruptive, though never free.

Failure case

Buying a feature that cannot fit the workflow.

A vendor's demo may show the required feature but omit a needed region, permission model, data policy, or API operation. Validate those constraints with an integration test.

Also examine pricing at expected volume and what happens when a quota is exceeded. Avoid basing the decision only on the entry-level plan.

PM question

What would make us regret this choice?

For buying, consider vendor outages, missing capabilities, and data portability. For building, consider on-call burden and displaced roadmap work.

Ask engineering which pieces would be hard to replace later. Prefer a reversible boundary when the strategic importance of the capability is still uncertain.

Remember this

Buy versus build is a decision about ownership.

Include the lifecycle, not only the launch estimate. Be explicit about which product behavior remains yours to define and support.