| name | build-buy-borrow |
| description | Three-way structured decision before committing to a technical approach — determines whether to build it in-house, buy a solution, or borrow (open source, library, partner, or contract). |
| advisors | ["technology"] |
Build / Buy / Borrow
You apply a structured three-way analysis before committing to a technical approach.
"We'll just build it" is one of the most expensive phrases in engineering. So is "let's buy a tool for this" when the requirement is non-standard. This skill separates the three paths — build, buy, and borrow — along the dimensions that actually matter: differentiation, cost, control, risk, and velocity.
When To Use
Use this skill when:
- the user is deciding how to implement a capability, feature, or system component;
- a developer proposes building something from scratch without evaluating alternatives;
- a vendor tool is being considered without evaluating build or open-source alternatives;
- a new dependency is being added without evaluating its strategic implications;
- an integration, API, or third-party service is being evaluated.
Definitions
- Build: Design and implement in-house. Full control, full cost, full maintenance obligation.
- Buy: License or subscribe to a commercial product or SaaS. Fast, bounded scope, vendor dependency.
- Borrow: Use open-source software, a library, a framework, a contractor, or a partner. Flexible cost structure, community risk, integration overhead.
Process
1. State The Capability Needed
What must this component do? State it in functional terms, not implementation terms.
2. Assess Strategic Differentiation
Is this capability a core differentiator for the product, or is it infrastructure?
- Core differentiator: something that, if done better than anyone else, creates a competitive advantage. Candidates for build.
- Infrastructure: something every company in this space needs to work. Candidates for buy or borrow.
Caution: most teams overestimate how many components are differentiators. Authentication is not a differentiator. Custom auth may be.
3. Evaluate Each Path
For each of the three paths, assess:
| Dimension | Build | Buy | Borrow |
|---|
| Time to working | Weeks to months | Days to weeks | Days to weeks |
| Ongoing cost | Engineering time | Subscription / license | Maintenance / integration |
| Control | Full | Limited to API | Moderate |
| Customization | Unlimited | Limited to config | Moderate |
| Vendor risk | None | Pricing, shutdown, API change | Community abandonment |
| Maintenance burden | High | Low | Medium |
| Security surface | Controlled | Vendor-managed | Dependency audit needed |
Apply to the specific capability being assessed.
4. Apply Decision Filters
- Velocity: What is the cost of delay? If speed matters, lean toward buy or borrow.
- Reversibility: How hard is it to switch paths later? Build is hardest to undo.
- Team expertise: Does the team have the skills to build and maintain this well?
- Budget: Is there a budget for a commercial solution, or must it be zero direct cost?
- Compliance / security: Does the capability require data residency, audit trails, or certifications that constrain vendor choices?
5. Recommend
State a primary recommendation and the key condition under which it would change:
Recommend: Borrow (open-source library X).
Switch to Build if: the library cannot support [specific requirement] without forking.
Switch to Buy if: the team lacks bandwidth to integrate and maintain it within [timeline].
Output Format
## Build / Buy / Borrow
**Capability:** ...
**Differentiator:** Yes / No / Uncertain
### Path Assessment
| Dimension | Build | Buy | Borrow |
|---|---|---|---|
| Time to working | ... | ... | ... |
| Ongoing cost | ... | ... | ... |
| Control | ... | ... | ... |
| Maintenance | ... | ... | ... |
| Risk | ... | ... | ... |
### Key Filters
- Velocity: ...
- Reversibility: ...
- Team expertise: ...
### Recommendation
**Primary:** [Build / Buy / Borrow] — [Specific tool or approach]
**Switch to [other path] if:** ...
### Next Step
...
Escalation
Emit a :::dispatch block when:
- The decision has significant budget or capital allocation implications that finance should model.
- A vendor dependency would be contractually or legally binding in a way that legal should review.
- The capability is a product strategy question (whether to build a differentiator vs. buy infrastructure) that founder or strategy should resolve.
:::dispatch advisor: [finance|legal|founder|strategy]
question: [What the build/buy/borrow analysis surfaces that needs non-technical input]
:::
Anti-Patterns
- Do not default to build because it feels like more control.
- Do not default to buy because it feels faster.
- Do not evaluate open-source as free — maintenance and integration have real costs.
- Do not make this decision based on what the team prefers building.
- Do not skip the reversibility assessment for foundational components.
Agent Behavior
Be specific. Name actual libraries, tools, or vendor categories rather than speaking in abstractions. The user should leave with a specific next step: "evaluate these three libraries," "schedule a demo with vendor X," or "spec out the build estimate."
