What It Actually Means
You are not buying a product. You are buying access to one, for as long as you keep paying, on terms the vendor sets and can change.
The Trade, Stated Plainly
What you get: no up-front build cost, no servers, no maintenance, updates arrive automatically, and you can start next week. For most standard business functions this is straightforwardly the right answer, and the alternative of building something equivalent would be indefensible.
What you give up: control over the roadmap, the price, and to some degree the data. The vendor decides what gets built, what gets removed, and what it costs next year. Features you rely on can be discontinued. Prices rise, particularly after acquisition.
Neither side of that is hidden. It becomes a problem when the software has quietly become the way the business runs, and the terms then change.
The Question To Settle Before Committing
Can you get everything out, in a usable form, yourself, today?
Not whether the vendor offers an export. Whether that export contains everything: records, history, attachments, notes, custom fields, and the relationships between them.
The common finding is that headline data exports cleanly and the surrounding context does not. Years of notes and uploaded documents are frequently the part that holds a business in place, and it is discovered at the point of leaving rather than at the point of buying.
Test the export early, while you have no intention of going anywhere. If it works, you have options and negotiating position. If it does not, you have a dependency rather than a supplier.
Where The Cost Actually Goes
Per-user pricing looks cheap and scales with headcount, which means it grows exactly as the business grows.
Three things routinely make the real figure much higher than the quoted one. Tiering, where the feature you actually need sits two levels up. Per-integration or API charges, which turn a connected setup into a considerably more expensive one. And seat creep, where licences accumulate for people who left.
An annual review of what you pay for and who is using it is unglamorous and reliably finds money.
Where Custom Makes Sense Instead
Not as a general alternative. In specific situations.
When the process is genuinely unusual and adapting your business to fit the software costs more than the software saves. When per-user costs have grown to the point where a build pays for itself in a couple of years. When the thing you do is the thing you sell, and running it on the same platform as your competitors removes the difference. Or when several tools are being connected with manual work between them, and one system covering the flow removes the whole seam.
Most businesses need both: standard tools for standard functions, and something built for the part that is actually theirs. Choosing entirely one way or the other is usually a mistake in either direction.
More terms are in the glossary.
