I’ve spent most of my career building bespoke digital platforms for organisations with very specific needs. And more often than not, I can tell within the first few conversations whether a product is going to succeed – or quietly struggle once it goes live.

The warning signs are rarely technical. The brief is usually detailed. The budget agreed. The roadmap impressive. On paper, everything looks solid.

The problem is almost always the same: the platform is being designed around assumptions about how people will use it, rather than evidence of how they actually do.

I’ve lost count of the number of times a client has arrived with a long list of requirements for a custom-built application – workflows mapped out, features prioritised, use cases debated – but no real plan for understanding what happens once real users get their hands on it.

There’s often a nod to “user testing” somewhere in the plan. A round of feedback before launch. Maybe another a few months later.

But real-world usage is treated as a milestone to check, not a signal to respond to.

And that’s where things usually start to unravel.

Because once a platform is live, usage rarely matches the neat logic of the original design. Features are ignored. Workarounds appear. Behaviour drifts. Adoption stalls – not dramatically, but quietly.

By the time anyone goes back to investigate what’s actually happening, the only options left are expensive redesigns, lengthy discovery phases, or complex rework projects that could have been avoided altogether.

Which is why so many bespoke digital platforms don’t fail loudly. They fail quietly – slowly fading away over time through underuse, friction, and missed opportunities to learn.

The real reason most digital tools don’t deliver

This pattern isn’t about poor execution.

Most digital tools don’t fail because they’re badly built. They fail because insight into real-world usage is treated as an occasional exercise, rather than a continuous input into how the product evolves.

When feedback is gathered as a one-off – at launch, at the end of a pilot, or after problems have already surfaced – it becomes retrospective rather than useful. It tells you what went wrong, but too late to fix it cheaply or easily.

And when gathering that feedback is slow, manual, or resource-heavy, organisations naturally avoid doing it often. The result is long gaps between insight cycles, followed by big, disruptive redesigns instead of small, iterative improvements shaped by user behaviour.

Insight doesn’t arrive too late because teams don’t care. It arrives too late because the process makes learning expensive.

Where feedback loops usually break down

In practice, most organisations struggle with three things:

1. Feedback is disconnected from usage
Input is collected separately from the moment of use – via surveys, workshops, or interviews that rely on memory rather than experience.

2. Insight lives in reports, not decisions
Findings are reviewed, shared, maybe even discussed – but rarely embedded into what gets built, changed, or prioritised next.

3. Analysis becomes the bottleneck
By the time feedback is cleaned, interpreted, and summarised, momentum has gone and the product has already moved on.

The result is familiar: lots of data, very little learning.

What “good” actually looks like

When real-world feedback is used well, a few things are true:

• Insight is gathered close to the point of use, not weeks later
• The same users are engaged over time, not constantly replaced
• Questions evolve based on previous responses, rather than resetting each cycle
• Patterns and friction points are visible early, not buried in spreadsheets
• Learning feeds directly into small, ongoing improvements

Instead of asking, “What should we rebuild?”, teams start asking, “What should we tweak next?”

That shift – from episodic feedback to continuous insight – is what separates tools that evolve from tools that stagnate.

Why this matters more in expert-led environments

This problem becomes even more pronounced in regulated, specialist, or expert-led sectors.

Whether you’re building tools for clinicians, pharmacists, researchers, or other professionals, your users are time-poor and highly discerning. They don’t have patience for platforms that don’t fit their reality – and they’re unlikely to shout when something doesn’t work. They’ll simply stop using it.

If you only check in with them occasionally, you miss the quiet signals: the workarounds, the drop-offs, the features that never quite land.

But when feedback is clearly used – and visibly shapes how a tool evolves – engagement improves. Not because the technology is clever, but because people feel listened to.

From big rebuilds to small, informed changes

Over time, this pattern fundamentally changed how I think about digital products.

It’s what led me to believe that insight shouldn’t sit outside the product lifecycle. It should be part of it.

Not as a heavyweight testing phase. Not as a post-mortem. But as a lightweight, continuous signal that helps teams understand what’s really happening – and respond while change is still cheap.

Because the most successful digital tools aren’t the ones that launch perfectly. They’re the ones that keep learning after launch.

The quiet difference between tools that succeed and tools that stall

The gap between a digital product that delivers value and one that quietly fades is rarely about ambition or intent.

It’s about whether real-world usage is treated as an ongoing conversation – or a box to tick and move on from.

When insight is continuous, action becomes incremental.
When insight is episodic, change becomes painful.

And that difference determines whether a digital tool evolves with its users – or slowly loses them.