Buying software you will still be living with in five years
Software evaluations are usually run as feature comparisons: a scorecard, a weighted total, a demo from each vendor. That process reliably picks the product with the best demo, which is a different thing from the product you will be glad you chose.
Features are the part that changes. Every serious vendor in a category ships the same feature list within about eighteen months of each other, because they all read the same lost-deal reports. What does not converge is the four things below, and none of them appears on a scorecard.
Whether buying is the right move at all is the build vs buy analysis; this is what to ask once you have decided to buy.
One: how do I get my data out
Ask for an export of your own data in a format you can read, as part of the evaluation rather than as a promise. Not an API you could theoretically use — an actual file.
This is the single highest-leverage question in software procurement, and the answer is often much worse than the sales conversation suggests. If leaving is expensive, every subsequent negotiation happens with you in a weak position, and vendors know precisely how weak.
Two: what does the pricing do at three times my size
Per-seat pricing that is reasonable at twenty users is sometimes ruinous at two hundred, and the discovery happens exactly when switching is hardest.
Get the pricing for the size you expect to be, in writing, and check what happens when you cross a tier. The pattern worth watching for is a step change that arrives with a feature you will need but do not yet.
Three: who does the integration work, and when it breaks
Almost no product exists alone. Establish which system holds the truth for each shared entity, how the sync works, and what happens when the two disagree.
“It integrates with your CRM” describes an existence, not a behaviour. The useful questions are how often, in which direction, and what the reconciliation story is when a record diverges. Vendors rarely have a crisp answer, and the quality of the answer is itself a signal.
Four: what happens when the vendor is acquired
Not a hypothetical. In mature categories it is the base case. Products get acquired, the roadmap you bought into gets absorbed, and the price changes at renewal.
You cannot prevent this. You can price it: how bad would a forced migration be, in months and money. That number is the real cost of the lock-in in question one, and it belongs in the decision.
What buying genuinely gives you
It is worth stating, because the build case is easy to romanticise. You get somebody else’s security patching, somebody else’s uptime, somebody else’s platform migrations, and a support line that is not your own team. You get a product improved by feedback from customers you will never meet.
Those are real and they are the reason buying is the right answer far more often than building. The four questions above are not an argument against buying — they are how you buy the one you will not regret.
Running the evaluation without a scorecard
Weighted scorecards feel rigorous and mostly launder a preference. The weights get chosen after people have a favourite, and small differences in weighting swing the total more than any real difference between the products.
A better structure: pick the two or three products that clear the four questions above, then run each one on a real workflow with real data for a fortnight. Not a pilot with a success criterion invented afterwards — one genuine process, run end to end, by the people who will use it.
Write down beforehand what would make you reject each product. That single sentence does more work than a forty-row matrix, because it forces the disqualifying condition to be named while it is still hypothetical rather than argued about once someone has a preference.
The output is not a score. It is a short list of what each product made awkward, which is the thing you will actually be living with.
What I would not claim
I cannot tell you which vendor in your category is the right one. That requires running the evaluation, and the answers to the four questions vary between competitors more than their feature lists do.
I would also flag my own position: I build software, so treat any advice from me on this side of the decision as coming from someone with an interest in the other one. The questions above are the ones I would ask if I were buying, which is the best I can offer as a check on that.
Related reading: what building actually commits you to covers the obligations on the other side. Buy and extend covers the middle path, which is where most of these decisions genuinely land. And when off-the-shelf fights your process covers the specific mismatch that makes a good product the wrong product.