What is a discovery project?

What is the meaning of a discovery project?

A discovery project, or discovery phase, is the first stage of building custom software. Its purpose is to remove assumptions and create a shared, written understanding of the project before committing to the main build. It is about research, analysis and planning, not coding. The aim is to define the problem, explore the requirements, and map out a solution that fits your business.

On our projects, this is not a separate item you buy. Discovery and scoping are included in the project price. We start by finding the real problem, which is often different from the one first assumed. This involves talking to the people who do the work, understanding their daily tasks, and identifying the actual points of friction or opportunity.

The most common sign we find in discovery is a spreadsheet kept next to the main system. Your business might run a standard software package, but if it has no proper place for something your team tracks, they will use a spreadsheet. That spreadsheet shows the gap between what the software does and what your business needs. The discovery process finds these gaps and turns them into a clear set of requirements.

Ultimately, discovery is about de-risking the project. By investing time up front to define the scope and plan the work, you avoid costly changes and misunderstandings later. It ensures that the software we build for you is the software you actually need.

What are the outputs of a discovery phase?

The main output of a discovery phase is not software, but clarity. This clarity is captured in a set of documents that form the blueprint for the build. Before any engineering begins, we produce a Business Requirements Document, a Software Design Document, and a software requirements specification. These documents are agreed with you, not just created for our own internal use.

Each document answers a different set of questions. They make the project's intent and design explicit so that your team and our team are working from the same plan. This detailed planning is how we conduct requirements engineering and business analysis within our discovery process.

We align our software requirements specification work with ISO/IEC/IEEE 29148. This is an international standard for software requirements. It ensures that the requirements we write are complete, consistent, and testable. This means we can prove the final system meets every point in the plan.

Crucially, the requirements documents we write can be taken to us or to any other team to build from. You own the plan. This gives you control and flexibility, ensuring the detailed thinking done during discovery remains a valuable asset for your business, regardless of who does the implementation.

Why is a written plan so important?

A software project without a written plan is like building a house without a blueprint. It invites delays, budget overruns, and a final product that nobody is happy with. The written plan that comes out of discovery is what protects your budget and keeps the scope from drifting. It serves as the single source of truth for the project.

Having an agreed plan allows for effective decision-making. When new ideas or requests come up during the build, they can be compared against the written scope. This makes it easy to see if a request is a small change or a significant addition that needs to be planned and budgeted for separately. This process prevents uncontrolled scope creep.

The plan also forms the basis for testing. Your team will conduct user acceptance testing against the requirements they approved at the start. This is a simple check: does the software do what we all agreed it would do? Without a written plan, testing becomes subjective and it is hard to formally sign off on the project.

Before we finalize the plan, we pressure-test scope, cost and timeline against real constraints, not best-case ones. This means the plan you approve is realistic and achievable. If you are considering a new software project, book a free discovery call and we can discuss how to create a solid plan for your idea.

How do you ensure the plan is correct?

A plan is only useful if it accurately reflects your business needs. We use several methods to ensure the discovery process captures the right details and the resulting plan is correct. The process is collaborative, involving your team at every key step.

First, we agree who signs off what before the build, so approvals never stall it mid-flight. This clarifies decision-making authority from the start. We identify the key people in your business who understand the process we are improving and have the authority to approve requirements.

Second, we agree how the software works and looks with you, using prototypes, before committing engineering time. A prototype is a clickable model of the application. It allows your team to experience the proposed solution and give feedback early, when changes are fast and inexpensive to make. This is much more effective than reviewing text documents alone.

Finally, we trace every requirement from business goal to user story to test case. This creates a clear line of sight from a high-level business objective all the way down to a specific feature and the test that proves it works. This traceability ensures that nothing gets lost in translation and that every part of the build serves a specific, agreed-upon purpose.

How long does discovery take?

Because discovery is an integrated part of our projects, its duration is built into the overall project timeline. For most projects, the intensive discovery and planning work is completed within the first few weeks. Discovery typically takes 2 to 3 weeks.

The exact time depends on a few factors. The complexity of the problem is the main one. A project involving multiple departments, complex business rules, or several integrations with existing systems will require more time for analysis and documentation. A more contained project will naturally be quicker.

The availability of your team is also important. The discovery phase requires input and feedback from the people who understand the business problem and will use the new system. Scheduling workshops and review sessions efficiently with your key staff helps keep the process moving forward.

We typically plan to demo running software to you every 2 to 3 weeks during the build. This provides regular opportunities to confirm our understanding and adjust course as needed. This iterative approach ensures the final product is a perfect fit.

How much does a discovery project cost?

You might ask this question expecting a separate price for the discovery work. With our approach, the answer is simple: there is no separate cost. We do not charge a separate discovery fee before quoting the build.

Discovery and scoping are included in every project we take on, and they are part of the price rather than a separate engagement. This means you do not have to commit to one fee just to find out what the full project will cost.

You get a fixed figure once the written scope is approved. This is a fairer and more transparent way to work. It aligns our interests with yours: to define the project correctly from the start and deliver working software for a predictable price. You then pay against milestones you accept, not just because a date has passed.

Key takeaways

• A discovery phase is about planning and analysis, not coding.
• The main goal is to create a written, agreed-upon plan before building.
• We include discovery in every project price, with no separate fee.
• The key outputs are documents like the BRD, SRS, and SDD that define the project.
• A proper discovery process protects your budget and prevents scope creep.
• You own the plan and can use it with any development team.