A few weeks ago I sat across from a prospective client who had just finished describing an ambitious new software platform his team believed they needed. He was articulate, passionate, and ready to move fast. Then he paused and said something I rarely hear at the outset of a conversation: “Before we commit to building anything, I want to pay you to tell me whether we actually should.”
That single sentence told me everything I needed to know about the kind of partnership we were about to enter. He wasn’t asking for sketches or wireframes. He was asking for clarity. And that is precisely what a well-run design discovery process is designed to deliver.
For the last twenty years I have watched organizations of every size pour time and money into custom software projects that, in hindsight, never needed to exist in the first place.
The pattern is familiar: a capable internal team identifies a genuine pain point, leadership agrees something must be done, and the default reflex is to brief an agency or product team to “design and build it.” What almost no one budgets for is the disciplined work that should come first — figuring out whether “it” is even the right solution.
Discovery is that disciplined work. It is not a polite prelude to visual design. It is a structured period of research, stakeholder alignment, process mapping, competitive analysis, and technical feasibility assessment. Its explicit purpose is to surface the real problem before anyone commits resources to a particular shape of solution.
As the Nielsen Norman Group has long emphasized, a proper discovery focuses the entire effort on the right problems rather than rushing toward premature solutions.
And sometimes — more often than the industry likes to admit — the clearest finding is that the organization would be better served by configuring an existing platform, adjusting internal workflows, or simply doing less.
Two years ago we were hired by a mid-sized financial services firm to run exactly this kind of discovery for a proposed client portal. The brief was textbook: modern interface, real-time dashboards, seamless integration with their CRM, mobile-first, the works. Six weeks later we presented our final recommendations. There was not a single screen mock-up in the deck.
Instead we showed them a side-by-side comparison: the projected cost and timeline of building the portal from scratch versus the effort required to stand up a carefully configured Salesforce dashboard with a handful of custom Lightning components and a clean external sharing model. The numbers were not even close. The Salesforce route delivered 85 percent of the value at roughly 20 percent of the cost and one-third of the time. More importantly, it eliminated years of maintenance liability, security overhead, and technical debt. The client’s leadership team spent less than ten minutes discussing the trade-offs before deciding to kill the custom build. We closed the project by handing them a detailed implementation roadmap and an introduction to a Salesforce partner we trusted.
That outcome did not feel like a failure. It felt like the highest form of service we could provide.
I have learned to treat these moments as professional successes rather than lost billings. When you have been in this field long enough, you understand that the most expensive design mistake is not an ugly interface. It is a beautiful interface that solves the wrong problem — or solves a problem that no longer exists once you look at it clearly.
Marty Cagan of Silicon Valley Product Group captured this reality well when he described product discovery as the process of validating whether there are real users who want the product and whether the proposed solution is usable, useful, and feasible — before heavy investment begins.
Yet the industry still operates under an unspoken assumption that discovery must lead to new design deliverables. Agencies worry that recommending an off-the-shelf solution will make them look dispensable. Clients sometimes feel they have wasted money if they don’t walk away with high-fidelity mock-ups. Both perspectives miss the point.
A responsible design partner is not a vendor of pixels; they are a strategic advisor whose job is to protect the client’s time, capital, and reputation. If the data shows that the highest-leverage move is to configure rather than create, then that is the recommendation we make. Full stop.
In practice, many experienced teams now openly recommend this approach. As multiple analyses of custom software versus off-the-shelf platforms show, when standard processes are involved, configuring a mature platform like Salesforce often delivers far better long-term value than building from scratch.
Normalizing this outcome is long overdue. Discovery should be sold and scoped as a self-contained engagement with its own success criteria: clarity, not comps. Clients should expect — and celebrate — when the process saves them from an unnecessary build. Designers should take pride in steering organizations toward simpler, faster, more sustainable paths even when those paths do not involve our craft in its most visible form.
Because at the end of the day, our value is not measured in the number of screens we produce. It is measured in the number of expensive mistakes we prevent.
If you are a leader wrestling with whether a new digital product is the right answer, my advice is simple: pay for discovery first. Not because it might lead to design, but because it might spare you from it. The best design decision I ever helped a client make was the one where we collectively decided not to design anything at all.