When You Do Not Need a Platform

Platforms are useful for a specific set of questions. Several of the most valuable things a programme finds need no software at all.

A practical decision about “When You Do Not Need a Platform” should test whether the proposed system changes a known workflow and whether the resulting data remains understandable and exportable. Teams assessing billable hours tracker 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.

What you already hold

Ticket data, including the free text, which almost nobody reads.

Workflow and approval systems, which record elapsed time by design.

Identity and access systems, which record how long provisioning takes.

Collaboration tools, which show meeting load.

Device management, which already reports patch state and age.

That is a substantial picture before anybody deploys an agent.

What costs an afternoon

Walking through onboarding yourself, timing each step.

Timing three common approvals end to end.

Counting the systems needed for one routine task.

Reading a hundred tickets rather than the category report.

Each of these produces specific, actionable findings and none requires procurement.

What costs a week

A short survey asking what wasted time last week. Its own note covers writing one that produces something.

Sitting with five people for an hour each while they work. Uncomfortable, extremely informative, and the thing nobody does.

Comparing a task's documented process against how it is actually done.

When a platform earns its place

Scale: when you need the same measurement across thousands of devices rather than a sample.

Technical detail you cannot get otherwise: crash causes, driver faults, memory pressure over time.

Continuous measurement, where the point is detecting change rather than describing the present.

Proactive detection: finding the hundred people with a failing disk before they notice.

Those are real and they are narrower than the sales case.

The order that works

Do the cheap things first.

They produce the list of problems, and the list determines whether the remaining questions need a platform.

Organisations that buy first spend a year looking for a use, which the previous note covers.

The honest trade

A platform costs licences, agent weight on every device, deployment effort, and somebody's ongoing attention.

It buys scale and technical depth.

Whether that trade is worth it depends entirely on what you found in the cheap pass, which is why the cheap pass comes first.

What to check

Have you read ticket free text, or only the category report?

Has anybody walked through onboarding and timed it?

Do you know how long your common approvals take?

And if you already have a platform, what did it tell you that these would not have?

The point

Do the cheap measurement first: ticket free text, an onboarding walkthrough, three approval timings.

It produces the list that determines whether you need a platform at all.

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.