How a software discovery phase works
Aranv’s short answer: a software discovery phase is a short stretch of research before any build. The team interviews users, maps the current process and systems, tests the riskiest assumptions and finishes with a written scope, a release plan and an estimate you can act on, or a clear reason not to build.
Discovery sits between deciding a problem is worth solving and committing to a build. A small group, often a business analyst, a designer and a senior engineer, spends time with the people who do the work, reads the documents they handle and inspects the systems involved, so that assumptions become facts before they become code. Our how we work page shows where discovery fits in an engagement.
A discovery workshop usually comes first: the sponsor, users and IT agree goals, walk the current process and list constraints. Interviews, system reviews and UI/UX design work on the main screens follow, while technical spikes probe the parts most likely to go wrong, such as an old API or an export nobody documented.
What a discovery phase turns into
From open questions to a build plan
- 01 Interview the people involved Users, managers and IT explain how the work runs today.
- 02 Map process and systems Each step, handoff, document and integration is drawn and checked.
- 03 Test the risky parts Clickable mock-ups and small technical spikes settle the hardest questions early.
- 04 Write scope and estimate A ranked backlog, release plan and phased estimate close the phase.
Discovery can also end in a decision not to build, which saves money too.
Four things a project discovery phase produces
Each output answers a question that would otherwise surface, at higher cost, in the middle of the build.
Process and system map
A diagram of the current workflow, the people at each step and the systems holding the data, including the spreadsheets nobody mentioned at first.
Tested key screens
A clickable mock-up of the screens staff will use most, tried by real users so missing steps surface before development begins.
Backlog and release plan
Requirements written as user stories, ranked and grouped into a first release and later phases, each stating what is in and what is out.
AI feasibility check
For AI features, a sample of your real documents or messages is run through a model to see what accuracy is realistic and where staff must review.
Inside the discovery workshop
The workshop sets the tone for the phase. In a few hours the people who fund, use and support the software agree the goal, walk the current process together and put every constraint on the table, from an existing vendor contract to a busy season when staff are hard to reach.
What we do
- Goal and success measures
- Current process walkthrough
- Systems and data inventory
- Constraints and deadlines
- Ranked problem list
- Open questions with owners
Discovery for AI features
An AI feature raises questions a normal build does not: is the data good enough, how accurate must the model be, and who checks its work. Discovery answers them with a sample of real inputs and a small test before anyone commits to the full build.
What we do
- Sample of real inputs
- Agreed definition of a correct answer
- Quick model test and error review
- Review step for staff
- Data handling and privacy notes
How we approach a project
The phase ends with documents any vendor could use: a process map, a ranked backlog, an architecture outline, a risk list and a phased estimate. That estimate is far firmer than one made from a feature list, as the custom software cost guide explains, and the guide to building an MVP picks up where discovery ends for a new product.
Discovery for AI work adds a data step: collect real inputs, agree what a correct answer looks like and run a quick model test. When the result is still unclear, an AI proof of concept comes next. The UK government’s Service Manual page on discovery is a useful outside view, and more planning topics sit in our guides for software and AI buyers.
How we work
- Research before code
- Decisions written down
- Risks tested, not assumed
Our Process
-
Name one decision maker
Choose the person who can settle scope questions quickly and make sure they can join the key sessions.
-
Collect real examples
Gather sample documents, reports, screenshots, exports and the spreadsheets staff actually use.
-
Book time with users
Reserve short sessions with front-line staff in each role, not only with their managers.
-
Agree what done looks like
Decide which documents the phase must deliver and how you will judge whether to go ahead.
How Aranv runs discovery
Time with the people who work
Most of our discovery time goes to the staff who handle the work every day, because they know the exceptions managers rarely see.
Documents you keep
Process maps, backlog, architecture notes and estimate are written so another team could pick them up, whatever you decide next.
Risky parts tried early
Old APIs, messy exports and AI accuracy are tested with small spikes during discovery, so the estimate reflects what the systems really do.
A recommendation, not a pitch
If configuring software you already own would solve the problem, or the project should wait, the final report says so.
Ready to act on this guide?
Ask our team in a 30-minute conversation.
Or see how we build it: Explore all services
Discovery phase questions
-
How long does a software discovery phase take?
It depends on the number of user roles, systems and open questions; a focused tool needs less time than a platform with several integrations. Agree a fixed length and a list of outputs before starting so the phase cannot drift.
-
Is a discovery phase worth paying for?
For anything beyond a small change, usually yes. It costs far less than rebuilding misunderstood features. Ask for its documents to become yours, so you can take them to any vendor. For a small, well-understood change, a scoping call may be enough.
-
What is the difference between discovery and a proof of concept?
Discovery decides what to build and in what order. A proof of concept tests whether one risky technical idea works at all, such as a model reading your invoices. Discovery may include a small proof of concept when one question blocks the plan.
-
What happens in a discovery workshop?
The sponsor, a few users and IT spend a structured session together. They agree the goal, walk the current process step by step, list systems and documents, name constraints and rank problems. The output is a shared map and a list of open questions.
-
What do we get at the end of discovery?
A process map, user roles, a ranked backlog, tested screens, an architecture and integration outline, a risk list, a release plan and a phased estimate, plus a clear recommendation, which can be not to build at all.
Let’s talk about your next step
Contact Aranv to discuss your workflow, current tools, and goals. Meet with our team or send an inquiry.
Book a meeting with our team
Choose an available date and time for a 30-minute conversation about your project.
Tell us about your project
Share a few details so we can discuss a useful next step.
Prefer email? sales@aranv.com