You have funding, you have selected your software development partner and you’re ready to begin development on your product. But instead of giving you a quote for development, your software partner gives you a proposal for a technical discovery. What is this and why is it necessary?

Think of the “Discovery Phase” as laying the foundation for your application’s design and development that follows. The main functions of discovery are capturing the vision of the product from you, ensuring that this vision is in line with the needs of end users, and performing an initial technical due diligence to validate that the product in question can be designed using current technology. The Discovery process allows the product development team time to build use case scenarios, identify functional requirements, prioritize and size product features, create timelines and estimates and summarize their findings into a development proposal.

“Before you build a custom house, you go to open houses, look at “Houzz” for ideas, talk to designers and architects, speak to your bank to understand your budget and determine your timeline for moving from your current house into a new house. THEN you engage an architect and builder to design and build your house.”

All of these things demonstrate to you that the team has a cohesive process, that risk is sufficiently mitigated, and that a schedule is outlined including milestones.

Discovery is one of the most important areas of product development. It provides an incredible amount of value and provides the client with accurate insight into the realistic time and costs of development. Yet, it is often the least understood and appreciated phase of the product development process. Many potential clients see the Discovery Phase as only a paid quote. This often creates friction between the development firm and their client. In many industries, quotes for the entire service are expected to be obtained before any work is done, “How much to paint my house?”, “How much to add a basement?”, “How much for a tile roof?”. However, in software development, it would be a disservice to customers to estimate the costs and timelines of developing their product without sufficient research into needs, goals, and existing systems. We would simply be guessing, otherwise.

Many clients are surprised to find that a discovery process doesn’t typically add any cost to the bottom line. The discovery process, formal or informal, would happen regardless of whether it is broken out on the front end of any venture or simply baked into the cost of development. More often than not, a deliberate discovery process saves valuable development time further into the project. It often helps avoid costly misunderstandings of the design goals as the project progresses.

“Discovery is so much more than a paid quote. The assets built during the discovery phase should help any product development team, the one you are speaking with currently, or a future one, understand the application you are trying to build. The delivery assets should enable you to speak with investors, stakeholders, current and future customers – all with a sense of getting input BEFORE YOU COMMIT TO A BUILD! A deliberate discovery is necessary to drive success for any client”

Two important points for Discovery Phases:

  • Discovery is the time to get to know your development team
    • Shifting development teams mid-development has ramifications in cost, timeline and knowledge transfer
    • The new team will have different opinions on how your product should be built – that opinion will cost you
  • Discovery reduces the risk for both the development team and the client
    • All learnings developed during discovery are portable
    • Planning and design are the least expensive items to change
    • It’s easy to date many development teams before you become married to one


Once a discovery phase is complete, you should expect a professional and polished plan for your application.  This all starts with a list of features included in your design and preferably a list of features not included in your design. The plan should include images that detail the architecture and why certain decisions were made as it pertains to your application, business needs, reducing cost, increasing performance, helping meet scalability needs down the road, etc. You should receive a list of technologies that will be used to support the features you requested. Costs should be clearly outlined for each of the tool and system decisions as it pertains to you taking ownership of a new shiny product. You don’t want to be caught in a situation where you have spent all your money on development and have half a product to show for it.

“Remember, it is always easier to plan features during discovery than it is to add certain things after development has begun.  This shouldn’t keep you from starting. You can always change your tire while driving down the road…and you can always add a basement to a house that is already built. It is just much more difficult!”