← Writing

Build vs Buy for Internal Tools: The 4-question framework senior PMs should memorize

Build vs Buy for Internal Tools: The 4-question framework senior PMs should memorize

Hook

Build-vs-buy debates often turn into religion: engineers want control, finance wants savings, PMs want speed. The fastest way out is to turn it into a structured decision with a few non-negotiable questions.

Thesis

Senior PMs don’t ‘pick a side.’ They define the decision boundary: what must be true for build to win, what must be true for buy to win, and how you’ll validate those assumptions quickly.

The 4-question framework

  1. Is this core to our differentiation? If yes, lean build. If no, buying is usually rational.

  2. What’s the integration surface area? The more systems it touches (auth, billing, data models), the higher the long-term cost of buying.

  3. What’s the failure mode? If downtime breaks trust or revenue, you may need deeper control, better observability, and stronger SLAs.

  4. What’s the true total cost over 24 months? Include build + maintenance, vendor fees, migration costs, security reviews, vendor lock-in, and opportunity cost.

A practical scoring grid (simple, not fancy)

Rate each option 1–5 on:

  • Time to value (next 90 days)
  • Flexibility (ability to fit your workflow)
  • Operability (monitoring, on-call burden)
  • Security/compliance fit
  • Long-term cost (24 months)

You’re not seeking perfect math. You’re seeking clarity on tradeoffs.

A common trap: ‘buy now, build later’

It sounds strategic, but often becomes expensive:

  • You design your product around vendor constraints.
  • Customizations pile up.
  • Data models drift.
  • Rebuilding later requires a migration you never planned.

If you choose buy, define an exit plan up front: data portability, contract terms, and what you’ll keep abstracted.

How to de-risk quickly

Run a two-week evaluation sprint:

  • Integrate the vendor in a sandbox.
  • Measure latency, reliability, and developer experience.
  • Validate compliance requirements.
  • Prototype the key workflows.

Treat it like a product experiment, not a procurement process.

Decision write-up template (one page)

  • Context + problem
  • Options considered
  • Evaluation criteria
  • Risks and mitigations
  • Recommendation + what would change your mind

This is what makes you look senior: you’re explicit about assumptions.

Actionable takeaways

  • Ask four questions: differentiation, integration surface, failure mode, 24-month cost.
  • Use a small scoring grid to make tradeoffs visible.
  • Avoid ‘buy now, build later’ unless you have a real exit plan.
  • Run a short evaluation sprint with measurable criteria.
  • Document assumptions and what evidence would flip your decision.