Software Asset Management Software

Software asset management, usually shortened to SAM, is the practice of knowing what software your organisation has licensed, what it has actually deployed, and whether those two numbers agree. The reason it gets funded is rarely tidiness. It is a vendor audit, a renewal with a true-up clause, or a bill that grew without anyone deciding it should.

We sell source code you clone and run yourself, and this is one of the categories where the recommendation is short: almost nobody should build a SAM tool. The reasons are specific and worth understanding, so this page spends most of its length on what the category involves and where the free options run out.

Discovery and entitlement are two different problems

The last row is the one that defeats spreadsheets. Licences are frequently not counted per person. They are counted per core, per socket, per named user, per concurrent user, per device, or per some vendor-specific unit with its own counting rules, and virtualisation changes the arithmetic again. Two organisations with identical installations can owe very different amounts.

That is why the tools in this category are worth their price when the estate is large: the value is in the entitlement model and the vendor-specific rules, not in the list of installed programs.

The build almost never makes sense

Discovery requires an agent on every endpoint, or integrations with the admin API of every SaaS product you use. That is not a weekend of work, it is a permanent surface with a permanent maintenance cost, and it is the part existing tools have already paid for.

Entitlement modelling requires encoding the licensing rules of vendors who change them. Getting that wrong in your own tool produces a number you trust and should not, which is worse than not having the tool. The whole point of the exercise is defensibility in an audit, and a homegrown calculation with no audit trail does not provide it.

If the estate is small, a spreadsheet listing contracts, renewal dates, seat counts and owners genuinely covers it, and the highest-value thing in that spreadsheet is the renewal date with a reminder attached. Most of the money saved in early SAM work comes from cancelling things nobody uses, which needs usage data and a calendar rather than software.

Where a build does happen

There is one shape where teams write their own, and it is not internal SAM.

Managed service providers and IT consultancies track licences on behalf of their clients, and they need each client's contracts, seats and renewals isolated from every other client, with their own margin and billing on top. Products built for a single organisation managing its own estate fit that badly. What those teams build is a multi-tenant records application with renewal alerting, which is a considerably smaller job than a SAM platform and a genuinely different one.

What you would start from here

There is nothing in this stack for software asset management. No discovery, no agents, no entitlement model, no licence metrics, no compliance position. Given that discovery and entitlement are the entire category, that gap covers essentially all of it, and any page implying otherwise would be selling a login screen.

What the Vault template contributes to the second branch above is the multi-tenant application: organizations as the boundary each client's contracts live in, roles and invitations so a client sees their own estate and nothing else, a Hono backend with Prisma and Kysely on Postgres, an admin app, and Stripe billing for charging the service.

You would write the contract and entitlement records, the renewal calendar and its notifications, and any reconciliation against usage data your clients provide. If that reconciliation needs real discovery, that is the point to buy a tool and integrate with it rather than build one.

For internal SAM, the sensible move is to close this page and look at the established products, or start with a spreadsheet of contracts and renewal dates if the estate is small enough. The packs below are only relevant if you are building the service version.