Tracks/R&D Capital Management/Module 3.5
Track 3 — R&D Capital Management

Module 3.5: Vendor & Platform Risk Assessment

Vendor criticality scoring, concentration risk analysis, and exit strategy planning. Know your dependencies before they become your problems.

3 Lessons~50 minIntermediate-Advanced
1

Lesson 1: Vendor Criticality Scoring

Not all vendors are equal risks. A logo design tool going down is an inconvenience. Your auth provider going down is a catastrophe. Categorize vendors by criticality to allocate risk management effort.

Criticality Tiers

Tier 1: System operational dependency (cloud provider, database, auth). Tier 2: Revenue-impacting (payment processor, CRM, email). Tier 3: Productivity (project management, design tools).

Tier 1: full redundancy plan. Tier 2: fallback procedure. Tier 3: accept risk.
Blast Radius Analysis

If this vendor disappears tomorrow: how many users are affected, for how long, and what's the revenue impact? A vendor with 100% blast radius = existential risk.

Map: vendor → affected systems → affected users → revenue at risk
Financial Health Assessment

Is the vendor profitable? What's their runway? A startup vendor with 6 months of runway is a different risk than AWS.

Check: Crunchbase funding, LinkedIn employee count trend, customer reviews for concerns
📝 Exercise

List your top 20 vendors. Score each: criticality tier (1-3), blast radius (% users affected), and financial health (stable/uncertain/risky). Rank by composite risk.

2

Lesson 2: Concentration Risk

Concentration risk occurs when too much depends on a single vendor, platform, or provider. If 100% of your infrastructure is on one cloud, you have maximum concentration risk.

Cloud Concentration

Running everything on AWS/GCP/Azure is simple but creates total dependency. A region outage took down multiple major sites in 2024 for hours. Multi-cloud adds complexity but reduces catastrophic risk.

Strategy: primary cloud + DR in a different provider for critical services
API Dependency Concentration

Building core features on third-party APIs (OpenAI, Stripe, Twilio). If the API changes pricing 5x or discontinues your use case, your feature breaks.

For each critical API: document the abstraction layer and switching cost
Talent Concentration

All infrastructure knowledge in one person (or one vendor's consulting team). If they leave, operations become fragile.

Minimum 2 people trained on every critical system. Document all runbooks.
📝 Exercise

Create a concentration risk map: for each critical system, identify the single point of failure (vendor, person, or region). Design a mitigation plan for the top 3 risks.

3

Lesson 3: Exit Strategy Planning

Every vendor relationship should have an exit plan. If the vendor becomes too expensive, gets acquired, or sunset their product — how long until you're on an alternative?

Switching Cost Estimation

Direct costs (new license, migration engineering) + indirect costs (productivity loss during transition, retraining, data migration risk). Usually 2-5x the annual vendor spend.

If switching cost > 3x annual spend: high lock-in. Negotiate multi-year pricing accordingly.
Abstraction Layer Investment

Building abstraction layers between your code and vendor APIs reduces switching costs from months to weeks. The cost of the abstraction is insurance against lock-in.

Target: every Tier 1 vendor dependency should have an abstraction layer
Data Portability

Can you export your data in a standard format? How large is the data? What's the migration timeline? Vendors that make data export hard are using lock-in as a retention strategy.

Test: actually try to export your data. The export that "works" on paper may not work in practice.
📝 Exercise

For your top 3 most critical vendors: estimate switching cost, check data export capability, and write a 1-page exit plan with timeline and budget.

← Module 3.4Next: Module 3.6 →
Unlock All — $199/yr