Most software problems do not start with code. They start with a business that has grown around spreadsheets, workarounds, duplicated data and a lot of admin that nobody intended to keep forever. That is exactly why the question of what should a discovery phase include matters. If the early work is vague, the build usually becomes expensive, slow or full of compromises that were avoidable.

A proper discovery phase is there to reduce guesswork. It gives you a clear picture of how the business actually operates, where the friction sits, what the system needs to do and what should happen next. It is not a box-ticking exercise before development starts. It is the part that stops you paying to build the wrong thing.

What should a discovery phase include in practice?

At a practical level, a discovery phase should include an honest review of the current operation, the people involved, the process gaps, the data involved, the systems already in use and the commercial priorities behind the project. It should also produce decisions, not just observations.

That last point matters. Plenty of discovery work creates a long document full of notes but very little direction. Useful discovery narrows things down. It clarifies scope, highlights trade-offs and gives everyone a shared understanding of what is worth building now, what can wait and what should be left alone.

For growing businesses, that usually means starting with the operational reality rather than the technology. The main question is not, “What software do you want?” It is, “How does the work get done today, where does it break down and what is that costing you?”

Understanding the real business problem

A discovery phase should begin with the reason the project exists. That sounds obvious, but it is often skipped. A team may ask for a new platform, a portal or a workflow tool when the real issue is inconsistent data entry, poor handovers between departments or reporting that relies on one person stitching information together manually.

If you do not define the business problem properly, you risk solving the symptom instead of the cause. For example, automating a bad process can make the wrong thing happen faster. Replacing spreadsheets with software can also fail if those spreadsheets are covering several distinct jobs that have never been properly separated.

This stage should pin down the commercial case. Is the goal to save admin time, improve accuracy, speed up quoting, reduce missed jobs, support growth, or give management better visibility? Usually it is a mix, but the priorities need to be clear because they affect every later decision.

Mapping current processes without pretending they are tidy

Most businesses do not run on clean process maps. They run on habit, experience and whoever knows the workaround. A useful discovery phase reflects that.

That means speaking to the people doing the work, not just senior stakeholders. The way a manager describes an order process and the way it actually moves through sales, operations and accounts can be very different. Discovery should capture the current flow as it really happens, including delays, duplicate steps, exceptions and manual checks.

This is where the hidden costs usually show up. Staff rekeying data. Jobs stalling because nobody knows who owns the next step. Customer information living in three places. Approval steps handled by email because the system does not support the process properly. These are not minor details. They are often the reason the project exists.

The people, roles and decisions involved

A strong answer to what should a discovery phase include also has to cover users and responsibilities. Bespoke software only works if it fits the people using it day to day.

Different roles need different things from the same system. A business owner might want visibility and reporting. An operations team might need speed and consistency. Admin staff may care most about reducing repeat entry and avoiding mistakes. If discovery only reflects one viewpoint, the final system can create resistance instead of improvement.

This is also the point to identify decision-makers. Projects slow down when nobody knows who can approve scope, sign off changes or settle conflicting preferences between teams. Discovery should make governance simple. It does not need layers of meetings. It just needs clarity.

Reviewing existing systems and constraints

Very few businesses are starting from scratch. They already have accounting software, CRMs, booking tools, shared drives, email-based approvals or industry-specific platforms that cannot simply be removed.

A discovery phase should review what exists, how it is used and where the pain points really are. Sometimes a business thinks it needs a brand new system when the real need is better integration between tools. In other cases, an existing platform is so restrictive that building around it becomes harder than replacing part of the workflow.

This is where nuance matters. Keeping an existing system may save money upfront but create ongoing manual work. Replacing it may improve operations but increase project scope and change management. Good discovery does not pretend there is always a perfect answer. It weighs up what is practical.

Data, reporting and handovers

Data is usually where operational problems become obvious. If teams are copying information between systems, relying on inconsistent naming, or storing key details in personal spreadsheets, the issue is not just inefficiency. It is risk.

Discovery should look at what data is needed, where it comes from, who updates it and who depends on it downstream. It should also identify what reporting the business actually needs. Not every project requires elaborate dashboards, but most growing businesses do need a better view of workload, pipeline, performance or delivery.

Handovers matter just as much. A lot of friction happens between teams rather than inside them. Sales passes incomplete information to operations. Operations updates delivery status but accounts cannot see it. Customer changes are agreed informally and never reflected in the job record. A proper discovery phase joins up those gaps.

Defining scope, priorities and what not to build

One of the most valuable parts of discovery is deciding what belongs in phase one and what does not. Without that discipline, projects get bloated quickly.

A good discovery phase should separate essential requirements from useful extras. Essential means the system cannot do its job without them. Useful extras may still matter, but they should not hold up delivery if they can be added later. This keeps projects commercially sensible and stops early enthusiasm turning into unnecessary complexity.

It should also challenge assumptions. If a feature sounds good but solves a rare edge case at significant cost, that needs to be said plainly. Likewise, if a manual step is still the best option for a low-volume exception, there is no need to force automation just because it feels more sophisticated.

Outputs a discovery phase should produce

Discovery needs tangible outputs. Otherwise it becomes a series of conversations with no practical endpoint.

The exact format can vary, but the outcome should usually include a clear problem definition, a mapped view of the current and proposed process, prioritised requirements, identified integrations, data considerations, technical constraints and a recommended delivery approach. In many cases it should also include an outline of phases, budget expectations and the main risks to address early.

The key test is simple. At the end of discovery, should a business be able to decide whether to proceed, what to build first and why? If the answer is no, the discovery work has not gone far enough.

What should a discovery phase include before development starts?

Before any development begins, there should be enough clarity to avoid building on assumptions. That does not mean every tiny detail must be finalised. Some points can be refined during delivery. But the core workflow, scope boundaries, user needs and technical direction should be settled.

This is also the point to identify project risks. If the business relies on a third-party platform with limited API access, that is a risk. If one process varies widely between teams, that is a risk. If the project depends on internal staff who have very limited availability, that is a risk too. Discovery should surface these issues while they are still manageable.

For many SMEs, the best discovery phase is not the longest one. It is the one that gets to the truth quickly and turns it into a sensible plan. That is often easier when the same person understanding the business problem is also capable of shaping the technical solution, because fewer things get lost between advice and implementation.

A discovery phase earns its value when it gives you confidence that the project is grounded in how your business actually works, not how someone assumes it works on paper. If that foundation is right, the build has a fair chance of being useful for years rather than just impressive at launch.