Why We Don’t Rush Discovery
Getting aligned early means fewer surprises later.
We’ve had projects come to us halfway built, good-looking websites, well-intentioned platforms but something’s off. The structure doesn’t support the content. The CMS frustrates the people who are supposed to use it. The experience works fine on paper but feels clunky in practice.
And almost every time, the same thing is missing: proper discovery.
Discovery isn’t a nice-to-have. It’s not a box to tick. It’s where we figure out what problem we’re actually solving. Because it’s very easy to design and build the wrong thing really well and much harder to undo that once it’s launched.
That doesn’t mean weeks of workshops or lengthy documents no one reads. It just means slowing down enough at the start to ask the right questions. Why does this site exist? Who needs it? What’s working now — and what’s just familiar? What are the frustrations the team might not be saying out loud yet?
We look at what content needs to do, not just what’s there today. We talk to the people who will manage the CMS, not just the ones approving the budget. We explore how internal processes actually work, so the digital side fits into something real, not ideal.
Good discovery saves time. It avoids expensive rework, vague feedback rounds, and internal debates that happen too late. It gets everyone aligned early, so that once we start building, we’re not guessing or second-guessing.
One of the most useful questions we ask early in a project is: what do you already know about this that we might overlook?
Because most of the answers – the blockers, the priorities, the patterns, are already in the room. Discovery is just how we find them.
So no, we don’t rush it. It’s not because we want to stretch timelines. It’s because we want to build things that actually do their job and last.