Last month, a client came to us wanting to build a customer portal. They had wireframes, a feature list, and a budget. They were ready to start.
We asked one question: "What's the most painful thing your customers do today that this portal would fix?"
Thirty minutes later, we'd cut the project scope in half and identified a completely different starting point. The original plan would have cost $80,000 and taken 4 months. The revised plan cost $35,000 and launched in 6 weeks.
That's what happens when you lead with questions instead of jumping to solutions.
The Discovery Questions
Here are the questions we ask every client before starting a project:
"What happens if we build nothing?"
This question forces clarity on the actual cost of the status quo. Sometimes the answer is 'not much' — which means the project isn't urgent and we should focus elsewhere. Other times the answer reveals hidden costs that justify a larger investment.
"Who touches this process today, and what do they hate about it?"
Feature lists are abstractions. Pain points are real. We'd rather hear 'Sarah spends 3 hours every Monday copying data between spreadsheets' than 'we need data synchronization capabilities.'
"What does success look like in 6 months?"
Not 'what features will be built' but 'what will be different about your business?' This shifts the conversation from outputs to outcomes — and outcomes are what actually matter.
"What's the smallest version of this that would be useful?"
Every project has a core that delivers 80% of the value and features that deliver the remaining 20%. Finding the core early means you can ship faster, learn from real usage, and make informed decisions about what to build next.
"What have you tried before, and why didn't it work?"
Most problems aren't new. Understanding previous attempts — and why they failed — prevents us from repeating the same mistakes. Sometimes the failure was technical. Often it was organizational.
Why Most Teams Skip These Questions
Asking these questions takes time. It delays the start of 'real work.' And it sometimes reveals that the project shouldn't be built at all — which doesn't feel like a win when you're billing for development hours.
But here's the thing: the 'real work' of software development isn't writing code. It's solving problems. And you can't solve a problem you don't understand.
The hour we spend asking questions saves weeks of building the wrong thing. That's not a delay — that's the most valuable work we do.
The Bottom Line
If a development team starts coding before they deeply understand your problem, they're not saving time. They're gambling with your money.
The questions we ask aren't just due diligence. They're the difference between software that checks boxes and software that changes how your business operates.