Building the Register Yourself

The technical core of SaaS management is not difficult. Deciding to build it anyway is frequently wrong, and for reasons that have nothing to do with difficulty.

What building involves

Three or four API pulls: identity provider, expense system, OAuth grants from your major platforms, endpoint management for hardware.

A reconciliation layer: the alias mapping described elsewhere, maintained by hand.

A store. A database, or for smaller estates a spreadsheet with a scheduled refresh.

Reports: unused seats, orphans, renewals ahead, unowned applications.

For a competent engineer this is days of work, and that is genuinely all the discovery amounts to.

What building does not give you

The workflow. Requests, approvals, review campaigns, renewal reminders with escalation, ownership confirmation. This is most of a commercial product and it is where the effort actually goes.

Vendor catalogue data. Commercial platforms maintain a mapping of merchant descriptors to known applications, which saves real reconciliation effort.

Maintenance. APIs change, platforms are replaced, the person who wrote it moves on.

Anyone to call when it breaks.

When building is right

A small estate, where a spreadsheet refreshed monthly is genuinely adequate.

An unusual requirement no product meets.

Data that cannot leave your environment, which is a real constraint in some sectors.

An existing internal platform — a service catalogue, a CMDB, a data warehouse — where this is a small addition rather than a new system.

Existing engineering capacity with a named owner for three years.

When it is not

When nobody will own it. An unmaintained pipeline degrades silently and the register becomes confidently wrong, which is worse than absent.

When the workflow is what you need. If the problem is that reviews do not happen and renewals are missed, a discovery script does not address it.

When the estate is large enough that reconciliation without a vendor catalogue is a full-time task.

When the driver is avoiding a licence cost that is smaller than the engineering time.

The middle path

Build the discovery, buy or borrow the workflow.

Pull the data yourself into whatever you already use — a database, a spreadsheet, an existing service management tool.

Use the tooling you have for approvals and reviews. Most organisations already own a workflow system and do not need a second one.

This is the arrangement most organisations should start with, and it establishes whether the workflow problem is real before paying for a platform to solve it.

The honest test

Who owns this in three years? A name and allocated time, or it will decay.

What are we actually buying? If the answer is discovery, build it. If it is the request-approve-review-renew cycle, buy it or build it deliberately, because that is the part that fails without a system.

Do we have fifty applications or five hundred? The answer changes everything, and organisations frequently answer from memory rather than from a count.

The three-year question

The decision that determines whether a built solution survives, asked before writing anything.

Who maintains this when the author leaves? A named role, not a team.

What happens when the identity provider's API changes? Which it will.

Who notices when a pull silently starts returning partial data? This is the failure mode that produces a confidently wrong register.

What is the documented handover? A script with no runbook is a liability.

How much time per month is allocated, formally, to maintaining it.

If any of these has no answer, buy or use existing tooling. A decayed internal pipeline is worse than a spreadsheet, because people trust it.

The spreadsheet that is genuinely adequate

Under a certain size, the correct architecture is unglamorous and it works for years.

One sheet for applications, the ten fields.

One sheet for hardware.

One sheet for the descriptor mapping.

Three monthly exports pasted in, with formulas doing the comparison.

Conditional formatting for renewal deadlines and stale records.

A dated copy each month, which gives you snapshots for free.

This handles fifty applications indefinitely and it costs nothing, breaks in obvious ways, and cannot be lost when a vendor relationship ends.