How My First Attempt at SingleView Became the Failure That Shaped Everything After
Every founder has that early idea — the one that made perfect sense at the time, seemed clever, well-structured, and valuable… until reality gently (or not-so-gently) reminded you that you’d misunderstood the real problem.
Every founder has that early idea — the one that made perfect sense at the time, seemed clever, well-structured and valuable… until reality gently (or not-so-gently) reminded you that you’d misunderstood the real problem.
For me, that moment was my first attempt at what would eventually become SingleView.
Except back then it wasn’t SingleView. It wasn’t a platform, it wasn’t an operating engine, and it wasn’t a unified view of anything. It was a document management solution — and while it wasn’t wrong, it wasn’t right either. What I built solved the symptoms, not the system, and that distinction changed the entire trajectory of my software philosophy.
The First Version: A Solution Looking at the Wrong Layer
In the beginning the idea was simple. Organisations were drowning in documents. Information lived in email chains, spreadsheets, attachments, versions and folders. Nothing was joined up, nothing was visible across teams, and nothing lived in one place.
So I built something to fix that: a structured, centralised document management tool, with clean interfaces, good categorisation and permission controls. A place where everything had a home.
It looked useful. It felt useful. Clients nodded and said, “Yes, this is what we need.”
Except it wasn’t. The real problem wasn’t documents, it was information. And the real value wasn’t a place to store files — it was a way to move knowledge.
The Moment I Realised It Wasn’t Enough
The turning point came during a consulting engagement, when a senior leader asked a simple question: “This is great… but where do I see what’s going on?” I pointed to the document library. They frowned.
Another colleague asked where it connected to their operational systems. It didn’t. Someone else asked how they would use it to track actions. We couldn’t.
And that’s when it hit me. I hadn’t built an operating platform — I’d built a filing cabinet. A nice filing cabinet. A modern, digital one. But a filing cabinet all the same.
The information wasn’t connected, and neither was the work, the processes or the insight. I had solved organisation, not orchestration. That realisation was painful, but necessary.
The Evolution: From Filing Cabinet to Information Highway
Once I saw the gap, I couldn’t unsee it. Documents weren’t the heart of the organisation — data was. Processes weren’t driven by files, they were driven by decisions. Information didn’t need a place to live, it needed a way to flow.
That was the moment SingleView’s true identity began to form, and it came down to changing the question four times over:
- From “Where do we store documents?” to “How do we connect every piece of information so people can make better decisions faster?”
- From “Let’s build a repository” to “Let’s build an ecosystem.”
- From “Give them access to documents” to “Give them a single version of truth.”
- From “Organise the paperwork” to “Connect the organisation.”
That mindshift changed everything. It gave rise to a multi-module architecture, live data flows, unified operational views and real-time dashboards; to linked processes instead of isolated tasks; to the concept of an “information highway”; and to a platform that now powers PMO, governance, exec reporting, facilities, IT, customer operations and more.
The document management idea didn’t die. It simply became one small part of a much bigger machine.
Why That “Failure” Was Essential
Looking back, the first version wasn’t really a failure — it was a prototype. And it left me with five things I still carry.
1. Solving the visible problem isn’t the same as solving the real one
Documents were the symptom. Disconnected information was the cause.
2. Clients describe what they feel, not what they need
People asked for better filing. What they needed was better flow.
3. Software shouldn’t just store — it should enable
Enable insight. Enable decisions. Enable action. Enable outcome.
4. Great platforms often start as small ideas that weren’t quite right
You build, you learn, you rebuild, you evolve.
5. The most valuable systems connect what is already there
Not replace it. Not duplicate it. Connect it.
Between them they laid the foundations for the philosophy I still follow today: software should reduce friction, connect information and give leaders clarity — not complexity.
Looking Back
The first version of SingleView wasn’t the platform it needed to be. But without building it, I would never have found the insight that shaped everything after.
It taught me to think beyond storage, beyond documents, beyond visibility, beyond forms and folders. It taught me to think in highways, not cupboards. In flows, not files. In systems, not screens.
Today, SingleView is the product I wish I had understood how to build back then — and it only exists because the early attempt wasn’t good enough.
Sometimes the best ideas are born in the moment you realise your first one wasn’t big enough.