Introduction
Most founders evaluate vendors based on features and price. Few evaluate how difficult it will be to leave. That mistake often becomes expensive later, not because the vendor was wrong at the time, but because the company changed and the contract did not.
The biggest vendor risk is rarely technology. It is dependency: data you cannot extract, code you cannot move, behaviour you cannot replicate, contracts you cannot exit.
This framework helps you pick vendors deliberately, with features, price and the cost of leaving all on the same page.
What it solves
What good vendor decisions deliver
-
Predictable cost as you grow
A vendor whose pricing scales with you in a predictable way is one you can plan around. Surprise price changes are one of the largest hidden costs in a software stack.
-
An exit path that exists
When the vendor stops fitting, leaves the market, or raises prices unreasonably, an exit path means the situation stays manageable. Without one, the leverage runs in one direction.
-
Data you own
Customer data, product data, analytics, if the vendor controls the export format, the access or the schema, the data is yours in name but the vendor's in practice.
-
Integration that does not lock you in
Some integrations sit at the periphery; others reshape the product around them. Knowing the difference up front determines how much leverage you keep over the relationship.
-
A vendor relationship that scales
Good vendors evolve with their customers. Bad vendors quietly become harder to work with as you grow more important to them, when that should be the opposite signal.
What it does not solve
What vendor selection will not fix
-
An unclear requirement
If you do not know what you need, you cannot evaluate who provides it. Vendor selection starts after the requirements are clear, not before.
-
Internal politics
Vendors are sometimes chosen because of who introduced them, not because they fit. Selection processes that do not separate the introduction from the evaluation produce predictable regret.
-
Bad data governance
If you do not have a strong view on who owns the data and how it moves, vendors will fill the vacuum with terms that work for them. Define your view first.
-
Slow procurement
Vendor selection takes time even when done well. If decisions take quarters internally, the right vendor will be locked in by competitors before yours arrives.
-
Team capability gaps
A vendor cannot replace a team that does not exist. Sometimes the right move is to build the team rather than outsource the capability to a supplier.
Decision tree
Six questions before you commit
Run every shortlisted vendor through these questions. The answers shape the contract more than the demo does.
- Question 01
Who owns the data?
No → Ask explicitly. Default contracts often grant the vendor implicit rights you would not agree to if they were stated.Yes → Confirm in the contract, not the brochure. Ownership clauses live in the legal terms, not the marketing. - Question 02
Who owns the source code or configuration?
No → Negotiate. Custom configuration, integrations and any code commissioned should belong to you, not be implicitly licensed to the vendor.Yes → Verify that 'owned' includes the right to take it elsewhere, not just to use it. - Question 03
How easy is migration?
No → Test the migration path before signing. A vendor whose export is undocumented or expensive is a vendor designing for stickiness, not for fit.Yes → Confirm with a specific migration scenario: what does it take to move to a competitor in 60 days? - Question 04
What happens if pricing changes?
No → Insist on a price ceiling, an indexation cap, or a no-surprise clause. Vendors raise prices; the question is how predictable the raise is.Yes → Verify the cap covers all line items, not just the headline plan. - Question 05
What happens if support disappears?
No → Test support quality during the evaluation. A vendor whose response time is poor during sales is rarely better after the contract is signed.Yes → Confirm the SLA, the escalation path and the recourse if it is missed. - Question 06
What is the exit strategy?
No → Write one before signing. If you cannot describe how to leave, you do not understand what you are signing up for.Yes → Confirm the exit covers data, integrations, customer communication and the timeline. A two-week exit and a two-year exit are different products.
Common mistakes
Five common mistakes founders make
- 01
Ignoring lock-in
Vendor lock-in is the most common hidden cost in a software stack. Migration costs, integration costs, retraining costs and data extraction costs all compound. Evaluating only the entry decision and not the exit decision is the most expensive omission in vendor selection.
- 02
Focusing only on price
The cheapest vendor is rarely the cheapest over three years. Hidden costs, surprise pricing tiers, expensive integrations, poor support, migration friction, usually overwhelm the entry-price savings within 18 months.
- 03
No exit plan
A vendor relationship without an exit plan is a relationship where the vendor has all the leverage. Write the exit plan before signing, even if you never need it. The act of writing it changes what you negotiate.
- 04
Not testing support quality
Sales-stage support is the best the vendor offers. Post-contract support is what you will actually get. Test response time, depth and willingness to help on a real question before signing.
- 05
Choosing based on features alone
Features are a snapshot; relationships are a film. A vendor with slightly fewer features but stronger customer treatment will outperform a feature-rich vendor with weaker customer behaviour within a year.
Alternatives
Patterns that reduce vendor risk
Four practical patterns for keeping leverage on your side of the table.
-
Pilot before committing
Run a paid 30-60 day pilot with a real workflow before the full contract. Vendors who refuse pilots are telling you something about how the post-contract relationship will feel.
-
Multi-vendor architecture for critical services
For genuinely critical infrastructure (payments, comms, hosting), design the integration so the vendor can be swapped. Adds short-term complexity; removes long-term dependency.
-
Open standards over proprietary formats
Prefer vendors who store data in open or widely-supported formats. Even a slightly inferior product on standards usually beats a superior product on proprietary lock-in over three years.
-
Annual reviews with renegotiation
Build a yearly review into the contract, pricing, performance, fit. Vendors take the relationship more seriously when they know the contract is genuinely on the table each year.
Ronald's rule of thumb
Choose a vendor as if you may need to leave them in two years.
Most vendor regret comes from decisions made on day one that look different on day 700. The vendor that looked equal on price and features can be very different on exit cost. Designing the decision around the eventual exit produces sharper choices today, and stronger negotiating posture every year after.
, Ronald · YourStartup.Expert
Summary
Summary
Vendor selection is usually framed around features and price. Those matter, but they are the two least durable parts of the decision. Ownership, exit, support quality and pricing predictability shape the relationship over years; features and entry price shape only the first month.
Use the six questions above to test every shortlisted vendor. The vendor that answers them most clearly, in writing, in the contract, with concrete examples, is usually the vendor whose relationship will scale with you. The others are usually betting that you will not ask.
Common questions
Choosing a vendor, answered.
The questions founders ask before they sign with a software supplier.
- What is the most important thing to check when choosing a software vendor?
- The exit. Most vendors look good at the entry, that is what the sales process is designed for. The difference between a good vendor and a costly one shows up when the relationship needs to change: when pricing scales, when support is needed, when the company outgrows the product. Evaluating the exit terms, data ownership and migration path before signing produces better day-one decisions and a stronger position every year after.
- How do I avoid vendor lock-in?
- Prefer open standards over proprietary formats, insist on documented data exports, own custom configuration and code, design critical integrations to be vendor-swappable, and write the exit plan before signing. Lock-in is rarely an accident; it is a design choice the vendor makes. Asking the right questions early shifts the design back toward your side of the table.
- Is the cheapest vendor always the right choice?
- Rarely over three years. Entry-price advantages are usually consumed by hidden costs, surprise pricing tiers, expensive add-ons, poor support quality, migration friction at exit. A slightly more expensive vendor with predictable pricing, clear data ownership and a working exit path is usually cheaper over the lifetime of the relationship than the lowest-cost option.
- What should be in every vendor contract?
- Clear data ownership, an export format and frequency you can use, a documented migration path, a pricing structure with caps or indexation, a defined SLA with recourse, named owners on both sides, a notice period for changes to terms, and an exit clause that covers data, integrations and timeline. If any of these is missing, the contract is incomplete, even if the document is long.
- How do I test a vendor before signing?
- Run a paid pilot on a real workflow for 30 to 60 days. Use real data, real users and a real problem. Test support during the pilot, submit a non-trivial question and observe response time, depth and tone. Talk to two existing customers about post-contract experience, not just sales experience. The pilot tells you more about the next two years than any demo will.