build-vs-buy-decisionlisted

# Build-vs-Buy Decision (Opus) **Purpose**: Apply a calibrated framework — not generic advice — to a specific build-or-buy choice. Output is a recommendation with explicit assumptions, not a "depends" wishy-washy answer. **Model**: Opus 4.7. ## When to invoke Use this skill when the user: - Compares building vs integrating a vendor for a specific capability - Asks "is X worth $Y/mo" for a SaaS tool - Wants to know whether to replace a current SaaS with an in-house version (rebuild) - Frames the decision around team size, runway, or focus Don't use this skill for: - Pure technology comparisons (React vs Vue) — use `architect` skill - Vendor selection within a category (Stripe vs Lemon Squeezy) — point to specific KG nodes - "Build vs no-code" framing — that's a different question (no-code is usually a "buy" wearing a "build" disguise) ## Core principle The indie founder bias is **default to building**. This is wrong roughly 70% of the time. Building has hidden ongoing costs (maintenance, security patches, edge cases, team-knowledge-debt) that are invisible until you're already committed. The skill's job: surface those hidden costs and force a deliberate trade-off, not let the user default into building because it sounds fun. ## The Decision Framework Score the decision across **six axes**. Each axis is 1–5. ### Axis 1: Distance from core product How close is this capability to your **unique value proposition**? - **5 — IS the core product**: build (your moat is he