The brief sounded straightforward enough. A membership organisation needed to separate memberships, subscriptions, payments and reporting across multiple organisations while still presenting a seamless experience to members. Various developers had attempted to solve it. Various approaches had been proposed. None of them had delivered the outcome the client needed.
When I first looked at the project, I assumed the challenge was technical.
It wasn’t.
The deeper I went, the more it became clear that the real difficulty wasn’t building the system. The difficulty was understanding the organisation well enough to know what the system was supposed to do.
Some members held annual subscriptions. Others held lifetime memberships. Some memberships were active even though the subscription attached to them was not. Different payments needed to be allocated differently depending on circumstances that weren’t immediately obvious. Over the years, workarounds had been created, exceptions had accumulated and small decisions had quietly shaped the way the organisation operated.
The software wasn’t struggling because the problem was impossible.
The software was struggling because nobody had fully mapped the rules.
Once those rules became visible, the path forward became surprisingly clear.
I’ve seen this happen repeatedly over the years.
A client asks for online bookings, only to discover that the real issue is that customers don’t understand which service they need.
A founder wants to automate a process, only to realise the team follows three different versions of that process depending on who is handling it.
A business wants a new website, only to uncover that nobody has ever clearly agreed on who their ideal customer actually is.
The technical request is usually genuine. It’s just not where the problem begins.
One of the things that fascinates me most about working with businesses is that the most important information is often the information nobody thinks to mention. Not because they’re hiding it, but because it has become so normal that they no longer see it.
A passing comment in a meeting. A spreadsheet somebody updates every Friday afternoon. A manual step that only happens when a particular type of customer comes through the door. A decision made years ago that everybody forgot about except the person still dealing with the consequences.
Time and time again, I’ve watched entire projects suddenly make sense because of one seemingly insignificant detail.
That’s also why I continue asking questions throughout a project rather than trying to gather every answer upfront. As the design develops, the user journey becomes clearer. As the user journey becomes clearer, questions emerge about what happens after somebody makes an enquiry, completes a booking or becomes a customer. Those questions reveal opportunities to improve how information flows through the organisation, how decisions are made and how data is captured, tracked and reported.
What starts as a website project often becomes something else entirely.
It becomes a process of discovery.
Founders frequently arrive with what feels like a complete brief, only to realise that building the website is the first time they’ve been forced to map how the business actually works. The act of creating pages, defining customer journeys and designing systems exposes assumptions that have never been written down. It reveals edge cases that only exist in somebody’s head. It highlights gaps between how the business believes it operates and how it operates in reality.
I’ve come to believe that this is why some projects feel unexpectedly difficult. The complexity isn’t in the technology. The complexity is in uncovering the reality hidden beneath years of habits, assumptions and unwritten processes.
Ironically, the projects people describe as impossible are often the ones that become simplest once the missing piece is found. Meanwhile, the projects that appear straightforward can become surprisingly complicated because every layer reveals another assumption that nobody realised existed.
The longer I do this work, the less I see websites, automations and systems as isolated projects. They’re really a lens through which businesses get to see themselves more clearly. Sometimes that clarity is uncomfortable. Sometimes it’s exciting. Almost always, it’s valuable.
In my experience, the real challenge isn’t building the system.
It’s understanding the business well enough to build the right one.
