Discovery is the phase of a software project that happens before any design or code. It is also the phase most clients undervalue, because it does not produce anything they can click on. What it produces is less visible but more valuable: clarity about what to build, why, and how.
I do not skip discovery. I have seen what happens on projects that do, and the pattern is consistent: the build takes longer than quoted, the first version does not quite fit the workflow, and the back-and-forth to correct it costs more than discovery would have.
What Happens When Discovery Gets Skipped
A few years ago I took over a project that had already been in development for four months. The client had hired a previous developer who started from a feature list and built fast. The problem was that the feature list described what the owner thought the system should do, not what the staff actually needed. The result was a quoting module that did not account for how jobs were actually priced in the field, a customer record structure that could not hold the job history the team needed to see, and an integration with their scheduling tool that had been bolted on late and was unreliable.
The client had spent roughly $28,000 to get to that point. I estimated another $18,000 to rebuild the core properly. A discovery engagement at the start would have cost them $2,000 to $3,000 and would have caught every one of those problems before a line of code was written. That is a pattern I have seen enough times that I now require discovery on any project above a certain complexity threshold.
What the Discovery Phase Actually Involves
Discovery is structured investigation. It is not a kickoff call and a list of features. It involves working through how the business actually operates, where the current tools fail it, what the users of the new system actually need, and what success looks like in concrete terms.
- Workflow mapping. Documenting the real workflow, including the workarounds and manual steps, not the ideal version. This is where most of the useful information lives.
- Data modeling. What records exist, how they relate, what needs to be stored, what needs to be computed. This shapes the architecture more than any feature discussion.
- Integration inventory. Every existing tool the new system will need to work with. How data flows in and out, what the integration points are, what the dependencies are.
- User roles and needs. Who will use the system, what they need to do with it, what their context is when they are using it. A field tech on a phone has different needs than an office manager on a desktop.
- Constraint documentation. Timeline, budget, compliance requirements, legacy system limitations. These shape what is possible and should be documented explicitly rather than discovered mid-build.
What a Workflow Document Actually Looks Like
One of the outputs I put the most time into is the workflow document. It is not a flowchart drawn in a presentation tool. It is a written record of what actually happens, step by step, when a real job moves through the business. Here is a stripped-down example for a home services company:
Current state: Lead comes in via phone or website form. Office manager enters contact info into CRM manually. Sends a text to the crew lead to check availability. Crew lead replies via text. Office manager calls customer back to confirm. Job details typed into scheduling software separately. Invoice created in QuickBooks at job completion by pulling from handwritten job notes.
Target state: Lead captured via website form and written directly to CRM with service type and job details. System checks crew availability against scheduling tool in real time. Automated confirmation sent to customer. Completed job triggers invoice draft in QuickBooks from CRM data. No manual data entry at any step.
That document, written out clearly, makes the integration requirements obvious. It also makes it obvious which steps involve judgment calls that cannot be automated and which are pure data movement that can be.
What Discovery Produces
By the end of a discovery engagement, there are several concrete outputs:
- A workflow document that captures the current state and the target state
- A data model that defines the entities, relationships, and key attributes
- A feature specification that describes what the system needs to do, from the user perspective, with enough detail to estimate accurately
- An integration map showing every connection the system needs
- A build estimate that is grounded in the spec, not a round number pulled from a general range
These documents are useful regardless of who does the build. If you do discovery with me and decide to hire someone else, you have a spec that any competent developer can work from.
What Separates a Good Discovery From a Bad One
A bad discovery is a long intake form and a polished slide deck. A good discovery is an uncomfortable conversation about where the current process actually breaks down. The difference is whether the person running the discovery is willing to push past the stated problem to find the real one.
I ask a lot of questions that clients do not expect. What happens when an exception occurs? Who decides? Where does that get recorded? What does the team actually do when the system does not do what they need? Those questions surface the workarounds, and the workarounds are where the real requirements live. A discovery that does not uncover the workarounds is not doing its job.
I also pay attention to who is in the room. If the owner is describing the workflow but the people who actually run it are not present, I ask to spend time with the people who use the system daily. The owner’s view of the workflow and the operator’s view are usually different in ways that matter for the build.
What to Expect in the First Meeting
The first meeting is not a sales call. I am not trying to sell you a build. I am trying to understand whether a build is the right solution at all. Expect me to ask about the current tools, where they fall short, what the team does to compensate, and what a working solution would need to accomplish in concrete terms. I will ask about timeline and budget not to scope you out but because those constraints shape what solutions are realistic.
I will probably ask you to walk me through a recent job from first contact to invoice. That exercise surfaces more useful information than an hour of feature discussion. By the end of the first meeting, I should have enough to tell you whether discovery is warranted, what it would involve, and roughly what it will cost.
Why Discovery Produces Better Estimates
Every software estimate is only as good as the spec behind it. A feature list produces a ballpark. A detailed spec produces an estimate you can hold someone to. The difference is in what the developer knows before they start.
When I quote a project after discovery, I know what integrations are involved, how complex the data model is, what the edge cases are, and what the user experience needs to accomplish. That knowledge makes the estimate accurate. Without it, I would be adding contingency to every line item to cover the unknowns, and the client would be paying for that uncertainty.
What Discovery Costs
Discovery is a paid engagement. My strategy rate is $500/hr, and a typical discovery engagement for a software project runs from a half-day to a full day depending on complexity. That cost applies toward the build if you move forward with me. If you do not, you still have everything the engagement produced.
At Salterra, I have done discovery for clients who ended up deciding the project was not justified, and a few who decided to go with an off-the-shelf tool that fit their needs. Both outcomes were the right outcomes for those clients, and the discovery investment helped them reach a clear decision faster than they would have otherwise.
If you want to understand the full scope of what custom software development looks like, the software development page covers the broader picture. If you are still in the diagnostic stage, how I scope a build gives more context on what the process looks like in practice.