Quick Navigation
- Start here — Differentiation vs commodity
- When to build
- When to buy
- When to partner
- When to participate
- Evaluating vendors
- Total cost of ownership
- Interoperability velocity
- Exit strategy
- Lock-in risk
- Putting it all together
- Cheat sheet
Before we start — the one thing to hold onto
Every technology capability in your organisation falls somewhere on a spectrum: from "this is why customers pay us" to "every company does this the same way." The sourcing decision — build, buy, partner, or participate — should follow from where on that spectrum the capability sits. I've seen teams build commodity capabilities because it was familiar, and buy differentiating capabilities because it was faster. Both mistakes cost years to undo.
Build what differentiates you. Buy what is commodity. Partner for capabilities you need but don't want to own. Participate in ecosystems — standards bodies, shared platforms, AI marketplaces — when the value is in the network, not in ownership.
Sourcing strategy isn't just about what you own or purchase. It's about how you participate in ecosystems. Federated AI marketplaces, shared data meshes, and open standards bodies mean organisations must evaluate not only vendor relationships but their position and velocity within interconnected platforms and communities.
Keep it in mind.
1. Differentiation vs commodity — The first question every sourcing decision must answer
Most sourcing decisions start with "should we build or buy?" — but that's the wrong first question. The right first question is: "Is this capability a differentiator or a commodity?"
The answer determines the sourcing approach:
flowchart TD
CAP["🎯 Capability"] --> DIFF{"Differentiator\nor Commodity?"}
DIFF -->|"Differentiator"| BUILD["🏗️ Build\nOwn it, control it,\nevolve it"]
DIFF -->|"Commodity"| BUY_DEC["🛒 Buy\nDo not reinvent\nthe solved problem"]
DIFF -->|"Adjacent"| PARTNER_DEC["🤝 Partner\nAccess without\nownership"]
DIFF -->|"Network"| PARTICIPATE_DEC["🌐 Participate\nEcosystem value\nover ownership"]
The differentiation test:
| Question | If yes | If no |
|---|---|---|
| Does this capability directly create customer value? | Differentiator | Commodity |
| Would losing this capability lose us customers? | Differentiator | Commodity |
| Is this capability unique to our industry or business? | Differentiator | Commodity |
| Do we need to evolve this faster than vendors? | Build | Buy |
The capability sourcing matrix:
| Differentiator | Commodity | |
|---|---|---|
| Core domain | Build — own the advantage | Buy — don't waste effort |
| Supporting domain | Partner — access without ownership | Buy — commodity |
| Generic | Participate — ecosystem value | Buy — absolute commodity |
Examples: Recommendation algorithm — differentiator, drives revenue → Build. User authentication — commodity, everyone needs it → Buy (Auth0, Cognito). Payment processing — commodity with regulatory complexity → Partner (Stripe, Adyen). Logging and monitoring — commodity, solved problem → Buy (Datadog, Grafana).
Differentiate or commodity — that's the first question. The sourcing decision follows from it.
Try it yourself — The classification test
Take three capabilities in your organisation. Classify each one:
| Capability | Differentiator or commodity? | Current sourcing | Should it change? |
|---|---|---|---|
| e.g. Recommendation engine | Differentiator | Bought | Yes — build |
If your sourcing doesn't match your classification, you're either wasting engineering effort or giving away your advantage.
2. When to build — What to own because it creates competitive advantage
Teams often default to building because it's familiar and fun. But building has a long-term cost — maintenance, evolution, operational burden. Build only what genuinely differentiates.
Build when the capability is a differentiator and you need control over its evolution:
flowchart TD
BUILD["🏗️ Build"] --> WHEN["When:\nDifferentiator\nUnique to your business\nMust evolve faster than market"]
BUILD --> COST["Cost:\nDevelopment · Maintenance\nOperations · Evolution\nTalent"]
BUILD --> RISK_BUILD["Risk:\nOngoing burden\nKey-person dependency\nSlower than buying"]
WHEN --> VALUE["✅ Value:\nCompetitive advantage\nFull control\nNo vendor dependency"]
Build checklist: This capability directly differentiates us from competitors. We need to evolve it faster than the market provides. We have (or can acquire) the talent to build and maintain it. We understand the ongoing maintenance and operational cost. We have a plan for what happens when key people leave.
The build cost model over 3 years: Development £500K year 1, £100K year 2, £50K year 3 = £650K. Maintenance £50K year 1, £150K year 2, £150K year 3 = £350K. Operations £30K year 1, £60K year 2, £60K year 3 = £150K. Evolution £0 year 1, £200K year 2, £200K year 3 = £400K. Total: £1.55M. Compare to buying: £200K/year = £600K over 3 years. Build costs 2.5x more — but if it differentiates, it's worth it.
When building goes wrong: Building commodity — spent £1M building something Auth0 does for £50K/year. No maintenance plan — built it, nobody maintains it, becomes legacy. Key-person dependency — only one person understands it; they leave. Feature creep — "while we're building it, let's add..." — scope explosion.
Build only what differentiates — everything else is a maintenance burden you don't need.
Try it yourself — The build cost
What's the real cost of building vs buying for your differentiator?
| Cost category | Build (3 years) | Buy (3 years) |
|---|---|---|
| Development / License | ||
| Maintenance | ||
| Operations | ||
| Evolution | ||
| Total |
If build costs more but differentiates, it's worth it. If it doesn't differentiate, you're wasting money.
3. When to buy — What to purchase because ownership adds no strategic value
Buying is the right choice for commodity capabilities — but teams resist it because they want to build. The discipline is accepting that most capabilities are commodity and that buying saves time, money, and focus for what matters.
Buy when the capability is solved and ownership adds no strategic value:
flowchart TD
BUY["🛒 Buy"] --> WHEN_B["When:\nCommodity\nSolved problem\nNo differentiation value"]
BUY --> COST_B["Cost:\nLicensing · Integration\nVendor management\nSwitching cost"]
BUY --> RISK_BUY["Risk:\nVendor dependency\nLimited customisation\nVendor roadmap mismatch"]
WHEN_B --> VALUE_B["✅ Value:\nSpeed to market\nNo maintenance burden\nFocus on differentiators"]
Buy checklist: This capability is commodity — multiple vendors provide it. Building it wouldn't differentiate us. The vendor's roadmap aligns with our needs. We understand the integration cost (not just the license cost). We have an exit plan if the vendor fails or becomes unsuitable.
Common buy mistakes: Buying based on features only — integration cost exceeds license cost. No exit plan — locked in when vendor changes direction. Underestimating integration — "it's a SaaS product, it will be easy" — it's not. Buying too early — committed before understanding the real need.
The buy evaluation: Feature fit — does it meet our requirements today? High weight. Integration cost — how much effort to integrate? High weight. Vendor stability — will they exist in 5 years? Medium weight. Roadmap alignment — does their direction match ours? Medium weight. Switching cost — how hard to replace if needed? High weight. TCO — total cost over 3-5 years, not just license. High weight.
Buy commodity — don't reinvent the solved problem. Focus your engineering on what differentiates.
Try it yourself — The buy evaluation
Take a commodity capability you're considering buying. Score the vendor:
| Dimension | Score 1-5 | Notes |
|---|---|---|
| Feature fit | ||
| Integration cost | ||
| Vendor stability | ||
| Roadmap alignment | ||
| Switching cost | ||
| TCO |
If any dimension scores below 3, you have a risk. If switching cost is below 3, you don't have an exit plan.
4. When to partner — What to access without owning
Some capabilities you need but don't want to own. Building is too expensive. Buying gives you a product but not the relationship. Partnering gives you access — with governance to manage the relationship.
Partner when you need capability access without the overhead of ownership:
flowchart TD
PARTNER["🤝 Partner"] --> WHEN_P["When:\nCapability needed\nOwnership not justified\nRelationship matters"]
PARTNER --> COST_P["Cost:\nRelationship management\nGovernance overhead\nDependency on partner"]
PARTNER --> RISK_P["Risk:\nPartner failure\nMisaligned incentives\nRelationship breakdown"]
WHEN_P --> VALUE_P["✅ Value:\nAccess without ownership\nShared investment\nRelationship leverage"]
Partner examples: Payment processing — regulatory complexity; building is expensive and risky. Identity federation — standards-based; partnering with IdP is simpler than building. Data enrichment — third-party data you don't own; access, not ownership. Specialised AI models — domain-specific models trained by experts; access via API.
The partnership governance framework: SLAs — define availability, performance, and support expectations contractually. Data — define what data is shared, how it's protected, and who owns it. Integration — define API contracts, versioning, and change management. Exit — define how to disengage — data export, transition period, cost. Review — regular review of partnership health — quarterly at minimum.
Partner for access without ownership — but invest in governance to manage the relationship.
Try it yourself — The partner check
For capabilities you're considering partnering on:
| Capability | Why partner instead of build/buy? | Governance in place? |
|---|---|---|
If you can't answer the first column, you haven't justified the partnership. If the second is "no," you're not managing the risk.
5. When to participate — Joining ecosystems, standards, and shared platforms
Sourcing strategy goes beyond build, buy, and partner. Organisations must evaluate their position in ecosystems — AI marketplaces, shared data meshes, open standards bodies. Participation is a strategic position, not just a procurement choice.
Participate when the value is in the network, not in ownership:
flowchart TD
PARTICIPATE["🌐 Participate"] --> WHEN_E["When:\nNetwork value\nShared infrastructure\nEcosystem standards"]
PARTICIPATE --> COST_E["Cost:\nContribution effort\nStandards compliance\nEcosystem governance"]
PARTICIPATE --> RISK_E["Risk:\nEcosystem failure\nGovernance capture\nSlow consensus"]
WHEN_E --> VALUE_E["✅ Value:\nNetwork effects\nShared cost\nInteroperability"]
Participation examples: Open standards body (e.g., OpenAPI, CNCF) — interoperability, talent attraction. Contribute: time, expertise, adoption. Shared data mesh — access to data across the ecosystem. Contribute: your data, quality standards. AI marketplace — access to models, training data. Contribute: models, data, feedback. Industry consortium — shared security, compliance frameworks. Contribute: best practices, audit results.
The participation evaluation: Network value — does participation create value that ownership cannot? Standards benefit — does adopting this standard improve our interoperability? Shared cost — does sharing infrastructure reduce our cost? Influence — can we shape the ecosystem direction? Exit cost — how hard is it to leave if the ecosystem fails?
Participate when the value is in the network — shared cost, shared standards, shared infrastructure.
Try it yourself — The ecosystem check
Which ecosystems are you participating in?
| Ecosystem | What you gain | What you contribute | Exit cost |
|---|---|---|---|
If you can't answer the first column, you're not getting value. If the last column is "high," you're locked in.
6. Evaluating vendors and ecosystem partners — What to assess beyond features and price
Most vendor evaluations focus on features and price. But features and price are table stakes. The real evaluation criteria are strategic: alignment, stability, interoperability, and exit cost.
A comprehensive vendor evaluation covers six dimensions:
flowchart TD
EVAL["📋 Vendor Evaluation"] --> FIT["✅ Feature Fit\nDoes it meet needs?"]
EVAL --> ALIGN["🧭 Strategic Alignment\nDoes their roadmap\nmatch our direction?"]
EVAL --> STABLE["🏛️ Stability\nWill they exist\nin 5 years?"]
EVAL --> INTEROP["🔗 Interoperability\nHow easily does it\nintegrate?"]
EVAL --> EXIT["🚪 Exit Cost\nHow hard to replace\nif needed?"]
EVAL --> COST_V["💰 TCO\nTotal cost over\n3-5 years?"]
The vendor evaluation scorecard:
| Criterion | Weight | Score 1-5 | Notes |
|---|---|---|---|
| Feature fit | 20% | ? | Does it meet current and near-term needs? |
| Strategic alignment | 20% | ? | Does their roadmap match our direction? |
| Stability and viability | 15% | ? | Will they exist and thrive in 5 years? |
| Interoperability | 15% | ? | How easily does it integrate? Standards-based? |
| Exit and switching cost | 15% | ? | How hard to replace if needed? |
| TCO | 15% | ? | Total cost over 3-5 years, not just license |
Deep evaluation questions: Feature fit — does it meet 80%+ of needs out of the box? What requires customisation? Strategic alignment — where are they investing? Does their direction match ours in 3 years? Stability — funding? Revenue? Customer base? Key-person risk? Acquisition likelihood? Interoperability — standard APIs? Data export? Migration tools? Exit cost — data portability? Contract terms? Integration depth? TCO — license + integration + training + operations + customisation + exit?
Evaluate vendors on six dimensions — features are only 20% of the decision.
Try it yourself — The vendor scorecard
Score your most significant vendor:
| Dimension | Score 1-5 | Risk if low |
|---|---|---|
| Feature fit | ||
| Strategic alignment | ||
| Stability | ||
| Interoperability | ||
| Exit cost | ||
| TCO |
Any score below 3 is a risk. If exit cost is below 3, you don't have an exit plan.
7. Total cost of ownership — The hidden costs of build and buy decisions
Most sourcing decisions compare the obvious costs — development cost for build, license cost for buy. But the real cost includes integration, maintenance, operations, training, and exit. TCO over 3-5 years is often 3-5x the initial cost.
TCO reveals the true cost of each sourcing option:
flowchart TD
OPTION["💰 Sourcing Option"] --> BUILD_TC["Build\nDevelopment + Maintenance\n+ Operations + Evolution"]
OPTION --> BUY_TC["Buy\nLicense + Integration\n+ Customisation + Operations"]
OPTION --> PARTNER_TC["Partner\nAccess + Governance\n+ Integration + Exit"]
BUILD_TC --> TCO["📊 TCO Over 3-5 Years\nThe real comparison"]
BUY_TC --> TCO
PARTNER_TC --> TCO
TCO components:
| Component | Build | Buy | Partner |
|---|---|---|---|
| Initial | Development | License + integration | Setup + integration |
| Ongoing | Maintenance + operations | License renewal + ops | Access fee + governance |
| Change | Evolution (expensive) | Customisation (limited) | Negotiation (relationship) |
| Hidden | Talent retention, key-person risk | Vendor lock-in, upgrade cycles | Relationship risk, exit cost |
| Exit | Decommissioning | Migration | Transition |
The TCO model template over 5 years: Build totals £2.1M. Buy totals £1.05M. Partner totals £920K. But if build differentiates, it's worth the extra cost.
TCO over 3-5 years is 3-5x the initial cost — compare TCO, not initial cost.
Try it yourself — The TCO calculation
What's the real TCO of your most significant sourcing decision?
| Year | Build | Buy | Partner |
|---|---|---|---|
| Year 0 | |||
| Year 1 | |||
| Year 2 | |||
| Year 3 | |||
| Total |
If you haven't calculated this, you're comparing the wrong numbers.
8. Interoperability velocity — How quickly can this partner be swapped, integrated, or replaced
The most important criterion in sourcing isn't features or price — it's how quickly you can change your mind. Interoperability Velocity measures how fast a partner or platform can be swapped, integrated, or exited. High velocity means low lock-in. Low velocity means high lock-in.
flowchart TD
IV["⚡ Interoperability Velocity"] --> HIGH["🟢 High Velocity\nStandard APIs\nData portability\nShallow integration"]
IV --> LOW["🔴 Low Velocity\nProprietary APIs\nData lock-in\nDeep integration"]
HIGH --> FLEX["✅ Flexible\nCan swap or exit\nin weeks"]
LOW --> TRAPPED["🔒 Trapped\nSwapping takes\nmonths or years"]
What increases Interoperability Velocity: Standard APIs (OpenAPI, GraphQL, gRPC). Data portability (export in standard formats). Shallow integration (few touch points). Abstraction layers (your code talks to your abstraction, not their SDK). Contract testing (can verify replacement works before switching).
What decreases it: Proprietary APIs and SDKs. Data stored in vendor-specific formats. Deep integration (many touch points throughout the codebase). Business logic in vendor platform. No abstraction layer.
Measuring Interoperability Velocity: API standardisation — OpenAPI, REST, gRPC = high. Proprietary, SDK-only = low. Data portability — CSV, JSON, Parquet export = high. Proprietary format, no export = low. Integration depth — 2-3 integration points = high. 20+ integration points = low. Abstraction — your code talks to your interface = high. Your code talks to their SDK = low. Estimated swap time — days to weeks = high. Months to years = low.
Interoperability Velocity is the key sourcing metric — how quickly can you change your mind?
Try it yourself — The velocity scorecard
Score your most significant vendor on velocity:
| Factor | Score 1-5 |
|---|---|
| API standardisation | |
| Data portability | |
| Integration depth (inverse) | |
| Abstraction quality | |
| Estimated swap time (inverse) |
If your total is under 15, you're locked in. If it's under 10, you're trapped.
9. Exit and switching cost analysis — Designing strategic relationships with a clear exit path
Every sourcing relationship should be designed with a clear exit path. If you can't describe how you would exit a relationship, you're already locked in — you just don't know it yet.
Exit analysis forces you to think about the cost and process of disengagement before you commit:
flowchart TD
ENTER["🚪 Enter Relationship"] --> DESIGN["Design Exit Path\nBefore committing"]
DESIGN --> DATA["Data Export\nCan we get our data out?"]
DESIGN --> INTEG["Integration Depth\nHow many touch points?"]
DESIGN --> CONTRACT["Contract Terms\nWhat are exit conditions?"]
DESIGN --> TRANSITION["Transition Plan\nHow do we migrate?"]
DATA --> COST["📊 Exit Cost\nQuantified before entry"]
INTEG --> COST
CONTRACT --> COST
TRANSITION --> COST
The exit analysis template:
| Factor | Question | Assessment |
|---|---|---|
| Data | Can we export all our data in standard formats? | Easy / Hard / Impossible |
| Integration | How many integration points need to change? | Count |
| Business logic | Is business logic in the vendor platform? | Yes / No |
| Contract | What are the exit terms? Notice period? Penalty? | Document |
| Replacement | Is there an alternative? How mature? | List alternatives |
| Transition | How long would migration take? | Estimate |
The switching cost model: Data migration — export, transform, import — often the largest cost. Integration rewrite — every integration point must be rewritten. Business logic re-implementation — if logic is in the vendor platform. Testing — full regression — the new system must work the same. Training — teams must learn the new system. Downtime — during transition. Parallel running — running both systems during migration.
Design the exit before you enter — if you can't describe how to leave, you're already locked in.
Try it yourself — The exit plan
For your most significant vendor relationship:
| Question | Your answer |
|---|---|
| Can we export all our data? | |
| How many integration points need to change? | |
| Is business logic in the vendor platform? | |
| What are the exit terms? | |
| How long would migration take? |
If you can't answer any of these, you don't have an exit plan. You have a dependency.
10. Lock-in risk — How to assess and manage strategic dependency on vendors and ecosystems
Lock-in is the cumulative effect of low Interoperability Velocity, high switching costs, and deep integration. It's not always bad — sometimes lock-in is a deliberate choice for speed or capability. But it must be deliberate, not accidental.
Lock-in risk assessment evaluates the strategic dependency on each vendor and ecosystem:
flowchart TD
LOCK["🔒 Lock-In Risk"] --> DELIBERATE["🟢 Deliberate Lock-In\nConscious choice\nAccepted for speed\nExit plan exists"]
LOCK --> ACCIDENTAL["🔴 Accidental Lock-In\nNo one chose this\nDiscovered too late\nNo exit plan"]
DELIBERATE --> ACCEPT["✅ Accepted\nMonitored\nExit plan maintained"]
ACCIDENTAL --> MITIGATE["⚠️ Mitigate\nAdd abstraction\nPlan exit\nReduce dependency"]
The lock-in register:
| Vendor / Platform | Lock-in level | Deliberate? | Exit cost | Exit plan | Review date |
|---|---|---|---|---|---|
| AWS | High | Yes | £2M, 18 months | Multi-cloud abstraction layer | Annual |
| Auth0 | Medium | Yes | £200K, 3 months | Standard OIDC, portable | Annual |
| Vendor X analytics | High | No | £500K, 12 months | None — needs creating | Quarterly |
Lock-in risk factors: API standardisation — standard APIs = low risk. Proprietary APIs = high risk. Data portability — standard formats = low risk. Proprietary formats = high risk. Integration depth — shallow = low risk. Deep throughout codebase = high risk. Business logic — in your code = low risk. In vendor platform = high risk. Alternative availability — many alternatives = low risk. No viable alternative = high risk. Contract terms — flexible exit = low risk. Long lock-in, penalties = high risk.
Lock-in mitigation strategies: Abstraction layer — your code talks to your interface, not their SDK. Medium cost — upfront investment. Data portability — regular exports in standard formats. Low cost — process discipline. Multi-vendor — use multiple vendors for the same capability. High cost — complexity and cost. Standards-based — choose vendors that implement open standards. Low cost — evaluation discipline. Exit rehearsal — practice the exit annually. Low cost — time investment.
Lock-in is acceptable when deliberate and monitored — accidental lock-in is a strategic failure.
Try it yourself — The lock-in register
List your significant vendor relationships:
| Vendor | Lock-in level | Deliberate? | Exit plan? |
|---|---|---|---|
Any "no" in the last column is accidental lock-in. Fix it.
Putting it all together
Here's the complete picture in one diagram. This is the mental model worth internalising.
flowchart TD
CAP["🎯 Capability"] --> DIFF{"Differentiator\nor Commodity?"}
DIFF -->|"Differentiator"| BUILD_F["🏗️ Build"]
DIFF -->|"Commodity"| BUY_F["🛒 Buy"]
DIFF -->|"Access"| PARTNER_F["🤝 Partner"]
DIFF -->|"Network"| PARTICIPATE_F["🌐 Participate"]
BUILD_F --> EVAL["📋 Evaluate\nTCO · Lock-in\nExit · Velocity"]
BUY_F --> EVAL
PARTNER_F --> EVAL
PARTICIPATE_F --> EVAL
EVAL --> VALUE["✅ Sourced Strategically\nRight approach\nClear exit path"]
The foundation:
Differentiate or commodity — that's the first question. Build what differentiates. Buy what is commodity. Partner for access. Participate for network value. Interoperability Velocity is the key sourcing metric. How quickly can you swap, integrate, or replace? High velocity means low lock-in. Design the exit before you enter. If you can't describe how you would leave a relationship, you're already locked in — you just don't know it yet. The wrong sourcing choice creates lock-in that takes years to undo. Choose deliberately. Evaluate the full lifecycle. Design the exit.
Cheat Sheet — All the key terms
| Concept | One-Line Memory | Key Action |
|---|---|---|
| Differentiation vs commodity | The first question | Build differentiators, buy commodity |
| Build | Control + cost | Only for differentiators |
| Buy | Speed + dependency | For commodity; evaluate TCO and exit |
| Partner | Access + governance | For capabilities you need but don't want to own |
| Participate | Network + standards | When the value is in the ecosystem |
| Vendor evaluation | Six dimensions, not just features | Features are only 20% of the decision |
| TCO | 3-5x the initial cost | Compare over 3-5 years |
| Interoperability Velocity | How quickly can you change your mind? | The key metric |
| Exit strategy | Design before entry | If you can't describe the exit, you're locked in |
| Lock-in | Deliberate is acceptable | Accidental is a strategic failure |
How to know if this landed
You'll know this has landed when someone stops asking "should we build or buy?" and starts asking "is this a differentiator or commodity?" Every significant capability is classified as differentiator, commodity, access, or network. Sourcing decisions follow the classification — build for differentiators, buy for commodity. Vendor evaluations cover six dimensions, not just features and price. TCO is calculated over 3-5 years for every significant sourcing decision. Interoperability Velocity is assessed for every vendor and partner. Exit plans exist for every significant vendor relationship. And lock-in is tracked in a register — deliberate lock-in monitored, accidental lock-in mitigated.
What changes when the mental model clicks
I've run this session with teams where they built commodity capabilities (authentication, logging) — wasting engineering on non-differentiating work, bought differentiating capabilities (fraud detection) — limited by vendor's roadmap, had no exit plans — discovered deep lock-in when a critical vendor changed pricing. The gap at the start is usually not about understanding sourcing — it's about classifying capabilities before deciding.
What changes after this session:
Teams stop building commodity and start buying it. The differentiation test — "does this directly create customer value?" — is always the moment things click. People stop treating vendor evaluations as feature comparisons and start treating them as strategic assessments. Their results get better. They stop getting locked in when the real problem was that they never designed an exit.
The TCO exercise tends to immediately change how teams evaluate sourcing decisions. They start calculating full lifecycle costs. Their decisions get better. They stop comparing license costs when the real problem was that integration was 3x the license.
Book a Workshop
Ready to make sourcing decisions that create strategic advantage instead of strategic dependency?
or
1-day workshop includes capability classification — differentiate or commodity for your real capabilities, sourcing decision exercise — build, buy, partner, or participate for each, vendor evaluation practice — score a real vendor on all six dimensions, TCO model creation — calculate full lifecycle cost for your significant decisions, Interoperability Velocity assessment — measure swap speed for your vendors, exit plan design — create exit plans for your most significant relationships, and build/buy/partner/participate decision framework + vendor evaluation scorecard + exit and switching cost analysis template.