Why Our Software Projects Start With a Discovery Phase

By LaunchLen Web Solutions Team

Many software projects arrive with a solution already in mind: “we need an app” or “we need these two systems connected.” Sometimes that idea is right. Sometimes the real problem sits one step earlier, in a process nobody has mapped.

A software discovery phase is how we find out which it is before anyone writes code. This post explains how discovery can work with LaunchLen Web Solutions Inc., what we can ask, and what the outcome can include.

What a discovery phase is for

A discovery phase is a short, structured period of research and planning at the start of a software project. Its job is to turn an idea into a clear problem statement, a set of requirements and a scope you can make decisions with.

Public guidance on digital services describes the same idea. The UK Government’s Service Manual says that before committing to building a service, “you need to understand the problem that needs to be solved,” and that you “should not start building” during discovery (GOV.UK Service Manual). It also suggests reframing a pre-defined solution as a problem to solve.

For a business, discovery can help you:

• Check the idea fits the problem. A custom build, a configured product, or a process change.
• Agree what’s in and out of scope. So everyone is working toward the same first version.
• Surface risks early, before they’re built into the design.
• Decide whether to go ahead. Stopping after discovery is a valid outcome. The Service Manual says it’s “not a failure” to stop if the research shows that’s the best thing to do.

It’s also why our custom software development services start with consultation and strategy: defining the problem, the users and what success looks like.

Who we talk to and what we ask

Discovery can start with a free consultation, followed by conversations with the people closest to the problem. That can include the owner or decision-maker, the staff who’ll use the software every day, and anyone who looks after the systems it needs to connect to.

Questions can include:

• What problem are you trying to solve, and what happens today because it isn’t solved?
• Who will use the software, and what are they trying to get done?
• What does success look like once the software is in use?
• What have you already tried?
• What can’t change? Contracts, legal requirements or existing systems.
• Who makes decisions, and who needs to sign off on scope?

The people doing the work can see friction that isn’t visible from the top, so it can help to hear from more than one person. We can agree the scope of discovery with you before it begins.

Mapping users, workflows and requirements

Next, we can map how the work happens now and how it could work with new software. The Government of Canada’s Digital Standards put this first: “Research with users to understand their needs and the problems we want to solve” (Government of Canada, Digital Standards).

Software requirements gathering in discovery can include:

• User groups. Staff, customers or partners, and what each needs.
• Current workflows. Each step today, including the spreadsheets and re-typing that fill the gaps.
• Automation opportunities. Repetitive steps that could be automated.
• Paper and handwritten work. Analog or handwritten steps that could be digitized.
• Future workflows. How the same work could flow once the software is in place.
• Requirements. What the software must do, what would be nice to have, and what it doesn’t need to do at all.
• Accessibility needs. The Digital Standards advise building in accessibility from the start and engaging users with distinct needs from the outset.

Here’s an illustrative example (not a real client): a trades business tracks jobs in a shared spreadsheet and sends quotes by email. Mapping the workflow shows the real delay is the hand-off between the office and the field, not the quote itself. That changes what the first version of the software should focus on.

Spotting risks and integration needs early

Some of the most useful discovery work is finding what could get in the way. The GOV.UK guidance lists constraints such as legislation, contracts, legacy technology, and existing processes and systems (GOV.UK Service Manual).

Risk and integration checks can include:

• Integrations. Which systems the software needs to exchange data with, such as a CRM, accounting or inventory system, and whether they offer an API or export.
• Data. Where it lives today and what needs to move into the new system.
• Personal information. What personal information the software will handle. PIPEDA sets out fair information principles, including accountability, limiting collection and safeguards, for private-sector organizations that handle personal information in commercial activities (Office of the Privacy Commissioner of Canada, PIPEDA in brief).
• Security. Common web application risks to plan for, using references such as the OWASP Top 10, which OWASP describes as “a standard awareness document for developers and web application security” (OWASP Top 10).
• AI features. If AI is part of the idea, where it would do a clear job and where a rules-based approach would do. Our guide to AI process automation vs RPA vs agentic AI explains the differences.

What you receive at the end

Discovery covers full requirements gathering and getting to understand your business. How you can use the written summary, including with your own team or another developer, can be agreed with you before discovery starts. The outcome can be a written summary. It can include:

• A problem statement and the goals the software needs to meet
• User groups and workflows, current and future
• A prioritized list of requirements, separating the first version from later ideas
• Risks, constraints and integration needs
• A map of the gaps, including what could be automated and which analog or handwritten work could be digitized
• A recommended next step, which could be a custom build, configuring an existing product, or not building at all

If you decide to go ahead, the build can be scoped from that document. Costs are scoped per project, based on what discovery finds.

What we can ask from you along the way can include:

• A main contact who can make decisions
• Time from the people who will use the software
• Any documents or screenshots that show how the work happens now
• Sample data where it helps, agreed with you in advance

As a new client, you don’t need to give us access to your systems. Credentials are needed only if the work involves integrating with an existing codebase, micro-SaaS or servers.

FAQ

What is a software discovery phase?

A software discovery phase is research and planning done before any code is written. It defines the problem, the users, the requirements, the risks and the scope, so the decision to build is based on evidence rather than assumptions.

Do we have to build with you after discovery?

Not necessarily. How you can use the discovery summary, including with your own team or another developer, can be agreed with you before discovery starts.

What if discovery shows we don’t need custom software?

That’s a useful result. If an existing product or a process change solves the problem, we’ll say so, and the summary can explain why.

Working with LaunchLen

We’re LaunchLen Web Solutions Inc., based in Kitchener, serving Waterloo Region and businesses across Ontario.

If you have a software idea, or a process that’s outgrown its spreadsheets, discovery is a practical first step. Tell us what you’re trying to solve and who it’s for.

Book a free consultation