Technology build vs. buy vs. partner analyzer

Purpose

Turn a fuzzy "should we build this ourselves?" debate into a structured, weighted decision by scoring the build, buy, and partner paths against six criteria that actually drive technology investment outcomes — and deliver a defensible recommendation with a scorecard leadership can act on and challenge.

When to Use

Invoke this skill when the user asks to:

• Decide whether to build in-house, buy a vendor solution, or partner for a capability
• Evaluate a make-vs-buy decision for a platform, service, or component
• Justify a build or buy recommendation to a leadership team or board
• Compare vendor solutions against building internally
• Assess vendor lock-in or dependency risk for a technology choice
• Prioritize where limited engineering capacity should go versus outsourced

Inputs Required

Before starting, collect:

• Technology need: The specific capability, platform, or component being decided on (e.g., "customer identity/auth," "recommendation engine," "billing system")
• Strategic role: Whether this is core differentiation, a supporting capability, or commodity infrastructure
• Time-to-market pressure: The deadline or window and what's riding on it
• Budget envelope: Rough capital and ongoing spend available, if known
• Internal capability: Current team skills, headcount, and hiring runway relevant to building this
• Known options: Any vendors, partners, or open-source tools already on the table
• Integration landscape: Key systems this must connect to and any compliance/data constraints

If budget or specific vendors are unknown, proceed with directional estimates and flag them as assumptions to validate.

Instructions

Step 1: Frame the Three Paths for This Specific Need

Define concretely what each path looks like for the stated need — not generically:

• Build: What the team would design, own, and maintain in-house
• Buy: The category of off-the-shelf/SaaS/licensed solutions that fit
• Partner: What a co-development, managed service, or vendor-embedded arrangement would cover

State the default assumption for each path (e.g., "Buy = a mature SaaS with API access; Partner = a systems integrator delivering a configured deployment"). This anchors the scoring.

Step 2: Set Criterion Weights

Assign a weight to each of the six criteria totaling 100%. Default weighting, adjusted based on the strategic role provided:

State the final weights explicitly and justify any deviation from defaults in one sentence each.

Step 3: Score Each Path on Each Criterion (1–5)

Score all three paths against all six criteria on a 1–5 scale (5 = strongest for that path). Apply these lenses:

• Strategic differentiation: Does owning it create moat? Build scores high only when this is genuinely core; commodity needs score build low.
• Time-to-market: How fast can this path deliver working capability? Account for hiring/ramp for build, procurement/config for buy, onboarding for partner.
• Total cost of ownership: 3-year view — include build's ongoing maintenance and opportunity cost, buy's recurring licensing and scaling fees, partner's markup and exit costs. Cheapest upfront ≠ highest score.
• Vendor lock-in risk: Data portability, contractual exit, proprietary formats, single-supplier dependency. Build scores highest here; buy/partner depend on standards and contract terms.
• Internal capability availability: Realistic assessment of whether the team can build and sustain this without starving other priorities.
• Integration complexity: How cleanly does each path fit the existing landscape and compliance constraints?

For each score, write one line of reasoning grounded in the inputs — never a bare number.

Step 4: Compute the Weighted Scorecard

Multiply each score by its criterion weight and sum per path. Present as a table:

Report weighted totals to two decimals.

Step 5: Deliver the Recommendation

Name the winning path clearly and commit to it. Then include:

• Why it wins: The 2–3 criteria that decided it
• The trade-off accepted: What the recommended path gives up versus the runner-up
• Hybrid check: Whether a phased or blended approach (e.g., buy now, build later; partner to bridge) beats a pure path — recommend it only if the scorecard supports it

Step 6: Risk Flags and Revisit Triggers

List the top risks of the recommended path and the specific conditions that should trigger reopening the decision — for example: usage crosses a cost threshold, the vendor changes pricing or is acquired, internal team gains the missing skill, or the capability shifts from supporting to core.

Output Format

• Structure: Path framing → weight table → per-criterion scoring with reasoning → weighted scorecard table → recommendation → risk flags and revisit triggers
• Length: 800–1,200 words
• Format: Structured document with two tables (weights, scorecard) and short reasoned prose elsewhere
• Sections: Path Definitions, Criterion Weights, Scoring Rationale, Weighted Scorecard, Recommendation, Risk Flags & Revisit Triggers
• Tone: Engineering leadership — decisive, cost-aware, unafraid to commit to a call and name the trade-off

Quality Checklist

Before delivering output, verify:

• [ ] All three paths are defined concretely for this specific need — not generic descriptions
• [ ] Criterion weights sum to exactly 100% and any deviation from defaults is justified
• [ ] Every one of the 18 scores (3 paths × 6 criteria) has one line of reasoning
• [ ] Weighted totals are computed correctly and reported to two decimals
• [ ] The recommendation commits to one path and names the trade-off accepted
• [ ] At least three revisit triggers are specified with concrete thresholds or events

Notes

• The most common failure mode is scoring "build" high on differentiation for a capability that's actually commodity — pressure-test whether owning it truly creates a moat.
• Total cost of ownership for building is routinely underestimated; always include ongoing maintenance and the opportunity cost of engineering time diverted from core work.
• A close scorecard (totals within ~0.3) usually signals a hybrid path — recommend "buy to bridge, build if it becomes core" rather than forcing a pure choice.
• When vendor lock-in is weighted heavily, contract terms (data export, exit clauses, pricing caps) matter more than the technology itself — flag these as negotiation priorities.

How to use this skill

This file is a Claude Code skill in Anthropic's standard format — markdown with YAML frontmatter at the top.

Installing in Claude Code:

• ~/.claude/skills/<folder-name>/SKILL.md — auto-loads in every session anywhere on your machine (recommended for skills you'll use across multiple projects)
• <your-project>/.claude/skills/<folder-name>/SKILL.md — auto-loads only when working in that project (recommended for project-specific skills)

Restart Claude Code or open a new session to register.

Using in Claude.ai, ChatGPT, Gemini, or other AI tools:

1. Drag this file into a new chat, or copy and paste its contents
2. Send your task or request as your next message — the AI will apply the skill where it fits

For Claude Code skill details: https://docs.anthropic.com/en/docs/claude-code/skills