What is an ISV, and how does it differ from other tech suppliers?

An ISV, independent software vendor, is a company that develops and sells a software product it owns, shipped to many customers in the same version or a handful of configurable variants. Buying from an ISV means buying a license or subscription to something that already exists, not a project built to measure: the customer adapts to the processes and limits the product imposes, not the other way around. This is the model of an off-the-shelf ERP, of a CRM sold on a per-seat plan, of any business software with a single codebase serving thousands of different companies: the vendor has a direct incentive to keep it generic, because any customization built for one customer is a cost the shared customer base does not pay for. Ownership of the code, the roadmap and priorities stay with the vendor: the customer influences them only indirectly, never by direct decision. It is one of four models for procuring technology, and the least flexible of the four.

The four models compared

Besides the ISV, which sells a product of its own that the customer adapts to, there are three other ways to buy technology, and mixing them up is costly. An independent consultant sells applied expertise inside the customer's specific context: they build on the real problem, not on an already-written product, which lets them adapt to almost any scenario, but ties delivery to the capacity of one person or a small team, without the scale a product replicated across thousands of installations has. A system integrator operates one level up: it neither writes its own product nor simply rents out time: it assembles pieces that already exist, often from several different ISVs, and its value sits in the assembly work, in making systems that would not talk to each other on their own talk to each other. The risk here shifts toward dependency on the assembler: if the system integrator disappears or stops supporting you, the architecture it built stays legible only to whoever put it together, and often no one else really knows how to touch it safely.

The point almost no one says out loud

Staff augmentation, IT staffing dressed up as consulting, is the fourth model, and the one brochures are least honest about: you buy person-days, not an outcome. Accountability for whatever ends up in production stays entirely with the buyer, because the seller has already invoiced the day regardless of the result. None of the four models is wrong in absolute terms: an off-the-shelf ERP is the right choice when the process it manages is already standard across an industry, and rebuilding it from scratch would be wasted effort. An Italian public body that needs to handle electronic invoicing correctly buys an ISV product, because that process is regulated and identical for thousands of entities: there is no point commissioning it as a custom build. The same body, if it needs to integrate healthcare data scattered across incompatible legacy systems, will more likely use a system integrator or an independent consultant, because there the problem is not standard and no shelf product solves it without deep adaptation.

The criterion, not the ranking

The right question is not which of the four models is best, because none of them is in absolute terms: it is which one fits the context at hand. Two questions matter. Who is accountable for the outcome when something goes wrong, the vendor of the product, the assembler of the pieces, the consultant, or does the risk stay with you regardless? And what stays in-house when the relationship ends: code you own and understand, as discussed under code ownership, or dependency on a product or a person that risks turning into the vendor lock-in covered elsewhere in the glossary? Choosing the supplier before answering these two questions is the most common mistake, and the most expensive one to fix halfway through a project.