All posts
GTM

Build, Buy, Prompt: A Casebook of 10 Real Decision Patterns for PMMs

By Beatriz6 min read

PMM Mindset · March 2026

Build vs buy is no longer enough. Prompt introduces a third path, but only for certain classes of problems.

The "build vs buy" framework worked when software choices were binary: you shipped code or you paid a vendor.

Now many teams can also prompt a workflow into existence with AI tools, at least for a while. That is legitimate leverage. It is also easy to misuse.

The recurring failure mode is prompt by default because the first hour feels fast—while twelfth-month reliability, data handling, and ownership were never designed.

To make better decisions under pressure, I use a short casebook of patterns. Here are ten I reach for in review meetings with product and GTM.

Pattern 1: One-off internal artifact

Decision: Prompt

Why: speed matters more than long-term maintainability.

Pattern 2: Repeated workflow with low risk

Decision: Prompt first, then buy if stable demand appears

Why: prompt validates need before you commit budget.

Pattern 3: Core customer-facing workflow

Decision: Buy or build, rarely prompt-only

Why: reliability and governance requirements are higher.

Pattern 4: Regulated or sensitive data process

Decision: Buy or build with controls

Why: prompt-only implementations often fail compliance expectations.

Pattern 5: Differentiating product capability

Decision: Build

Why: if this is your advantage, outsourcing logic is risky.

Pattern 6: Commodity operation (summaries, formatting, tagging)

Decision: Buy or prompt

Why: little strategic upside to custom build.

Pattern 7: Cross-team workflow with many handoffs

Decision: Buy

Why: integration and admin overhead dominate here.

Pattern 8: Team lacks implementation bandwidth

Decision: Buy or prompt, avoid build

Why: opportunity cost of build is too high.

Pattern 9: High-variance exploratory work

Decision: Prompt

Why: ambiguity favors flexible iteration.

Pattern 10: Mission-critical system with long horizon

Decision: Buy with strong exit path, or build if strategic

Why: durability and ownership outweigh short-term convenience.

The Practical Scoring Matrix

Score each option (build, buy, prompt) on 1-5 across:

  • -->speed to value
  • -->total cost over 12 months
  • -->reliability needs
  • -->governance and risk
  • -->strategic differentiation
  • -->maintenance burden

Then choose the option with best weighted score for your actual context.

Do not use generic weights. A startup with 2 engineers should not score like an enterprise platform team.

Guardrails for Prompt-First Teams

If you choose prompt, set boundaries early:

  • -->define data handling policy
  • -->document failure modes
  • -->define when to graduate to buy/build
  • -->assign ownership

Prompt can be a great wedge. It is a poor permanent architecture for many high-stakes workflows.

What PMMs Should Own

PMMs should not just observe these decisions. We should influence them.

Why:

  • -->messaging depends on what is truly differentiated
  • -->pricing and packaging depend on delivery model
  • -->GTM risk increases when internal workflow decisions are opaque

The build-buy-prompt decision is now a narrative decision as much as an operations decision.

Bottom Line

Adding "prompt" to the framework is useful only if we apply it with rigor.

Use pattern-based thinking, score options against context, and treat prompt as a tool in the system, not the system itself.