Build, Buy or Use What You Have

The choice is presented as build or buy. The third option — use what is already deployed — covers more of the need than most organisations assume.

A practical decision about “Build, Buy or Use What You Have” should test whether the proposed system changes a known workflow and whether the resulting data remains understandable and exportable. Teams assessing this working reference can include time, project ownership and reporting in that pilot, while keeping privacy, security and employee consultation as explicit requirements rather than optional settings.

For an independent benchmark, compare this approach with UK Technology Code of Practice; the useful test is whether the evidence remains proportionate, accessible and understandable to the people whose work is being measured.

Use what you have

Device management already reports boot time, hardware specification, patch state and installed software.

The service desk holds ticket detail.

Workflow systems record approval elapsed time.

A survey tool exists somewhere in HR.

Together these answer a surprising share of the questions, at no additional cost and with no new agent.

Try this first. It also tells you what is genuinely missing, which is the specification for anything you buy.

Build

Viable where the questions are narrow and the data is already available.

A script collecting login phases, a query against the ticket database, a monthly survey, and a small reporting layer.

Costs: somebody's ongoing time, and it becomes their responsibility indefinitely.

Appropriate for: specific recurring measures. Not for: estate-wide continuous telemetry, which is a product problem.

Buy

Appropriate where you need depth and scale that the existing tooling does not reach: crash causes, memory pressure over time, application-level transaction timing, proactive detection.

And where continuous measurement across thousands of endpoints is the point.

Costs: licences, agent footprint, deployment, and an owner.

The sequence

Use, then build the gaps that are narrow, then buy what remains.

Most organisations reverse it, buy first, and discover afterwards that half the platform duplicates what they owned.

The hidden cost of buying

Not the licence. The agent on every machine, the deployment project, the integration effort, and the ongoing attention.

Budget the attention explicitly, because it is the one that is never allocated and it is what determines whether anything happens.

When building goes wrong

It works and becomes one person's unsupported system.

They leave, and the measurement stops.

If you build, document it and make sure two people can run it — which is the succession problem and applies here exactly.

The honest comparison

A bought platform gives you more data sooner and a maintenance commitment.

Built or existing tooling gives you less data and no new dependency.

Which is better depends on whether you have the organisational capacity to act on more data, and most organisations overestimate that.

What to check

What do your existing tools already report?

Have you tried answering your top three findings with them?

If you built something, could two people run it?

And have you budgeted attention as well as licences?

The point

Use what you have, build the narrow gaps, buy what remains.

Most organisations reverse it and discover half the platform duplicates what they owned.

Underlying all of this

Everything in this collection reduces to four habits: find the friction cheaply before buying anything, fix what needs no budget first, report the worst tenth rather than the average, and keep the data about systems rather than about people. None requires a better platform, and a programme doing all four changes more than one twice its size.

The recurring pattern

The recurring pattern across every section here is the same: the measurable is mistaken for the important. Device health stands in for experience, ticket categories for causes, a composite score for a finding. Each substitution is convenient, each produces confident decisions on thin ground, and each is corrected by going and looking at the thing itself.