The Client Who Wanted to Skip the Talking Part
A few years ago, a business owner called me with a clear goal. She ran a small logistics company, and she wanted an app for her drivers. "I don't need meetings," she told me. "I need you to start building."
I understood the feeling. Meetings feel slow. Building feels like progress. So I get why she wanted to skip straight to the fun part.
We talked her into two weeks of planning first. She wasn't thrilled about it. But three months later, she thanked me for insisting.
Here's why. During those two weeks, we learned her drivers didn't all use the same type of phone. Some had old Android devices with no reliable signal in the areas they drove through. If we had started coding on day one, we would have built an app that half her drivers couldn't use. We'd have found out after it was finished — the most expensive time possible to find out.
That two-week delay saved her, by our own rough estimate, at least six weeks of rebuilding later. This is the story I think of every time someone asks me why we can't "just start building."
What a Discovery Phase Actually Is
A discovery phase is simply the time you spend understanding a problem before you try to solve it.
Think about hiring someone to renovate your kitchen. A good contractor doesn't show up with a sledgehammer on day one. They ask what you cook, how your family uses the space, where the plumbing runs, and what your budget really is. Then they draw a plan. Only after that do they start knocking down walls.
Software works the same way. Before anyone writes a single line of code, someone needs to understand:
- Who will actually use this software, and how
- What problem it needs to solve
- What already exists that it needs to work with (like your accounting software or your website)
- What "done" looks like, so everyone agrees on it later
That's it. It's not a technical process. It's a conversation, done carefully, with the right questions.
What Happens During It, in Plain Language
A discovery phase is usually one to four weeks, depending on how big the project is. During that time, a good developer or consultant will:
- Ask you a lot of questions. Not just "what do you want," but "who else will use this," "what happens if this data is wrong," and "what do you do today without this software."
- Watch how you currently work. Sometimes the best answers come from watching someone use a spreadsheet or a paper form, not from asking them to describe it.
- Write down what they learned, in plain language you can read and correct. This is usually a short document, not a technical spec.
- Sketch what the finished product might look like, often with simple drawings or mockups, before any real building starts.
- Flag the hard parts early — the things that might cost more, take longer, or need a decision from you.
At the end, you should have something in writing that both sides agree on. If a disagreement is going to happen, this is where it happens — while it only costs a conversation, not a rebuild.
What Goes Wrong Without One
I want to be specific here, because "skipping planning is risky" is vague, and vague doesn't convince anyone.
Here's a very common pattern. A business owner hires a developer and says, "build me a website where customers can book appointments." The developer, eager to get started, builds exactly that. Three months later, the owner opens it and asks, "where do I see all of today's bookings in one place?" Or, "how does this connect to the calendar my staff already use?"
Nobody asked those questions up front. Not because anyone was careless, but because nobody set aside time to ask them. Now the developer has to go back, and often has to rebuild parts of the system that were built assuming something that wasn't true.
This is one of the most well-documented patterns in software development: a misunderstanding is cheap to fix while it's still just a conversation. The same misunderstanding is expensive to fix once it's built into working code, because now something has to be undone before it can be redone. It doesn't need a fancy statistic to make sense — think about how much cheaper it is to change your mind about a paint color before the room is painted versus after.
I've written before about the mistakes business owners make before starting a software project, and skipping this step is the single biggest one. It's not that people are careless. It's that "let's just start building" feels productive, while asking questions feels like a delay. In reality, it's the opposite.
How to Make Sure Whoever You Hire Actually Does This
Here's the good news: you don't need to become technical to protect yourself. You just need to ask the right questions before you sign anything.
Ask any developer or agency you're considering:
- "What does your discovery phase look like, and how long does it take?"
- "What will I have in writing at the end of it?"
- "Who from my team do you need to talk to, and for how long?"
- "What happens if we skip this step?"
A good answer sounds confident and specific. A vague answer — "don't worry, we'll figure it out as we go" — is a warning sign. "Figuring it out as we go" often means figuring it out with your money, after something has already been built the wrong way.
If you're comparing options, this is also one of the clearest signals of how a partner actually works. I cover more of this in how to choose a software development partner — a real discovery process is one of the fastest ways to tell a thoughtful partner from one who just wants to start billing hours.
The Short Version
Discovery isn't a delay before the real work starts. It is the real work — the part where expensive mistakes are still cheap to catch. Skipping it doesn't save you time. It just moves the cost to later, and makes it bigger when it arrives.
If you're about to start a software or website project and you want someone to ask the hard questions before writing any code, I'd be glad to talk it through with you.