What Happens in Discovery Before a Software Project Starts

A UK retailer evaluating an India-based partner sends over a feature list: inventory module, approval workflow, mobile app for the warehouse team. Within four days, a quote arrives. Fixed price, eight weeks, a module-by-module breakdown that reads back their own words.

That speed should worry the buyer, not reassure them. No one can know how a business actually approves a purchase order, or why the warehouse team bypasses the system twice a week, in four days without talking to anyone who does the work. What arrived is a priced feature list, not a scope built on how the business runs.

What does discovery actually mean before a project starts?

Discovery is the work a transformation partner does before writing a scope: mapping the current process, naming who decides what, and finding where the delay or rework actually happens. It is not a requirements-gathering call. It is closer to how an auditor opens a file, by asking what happens, in what order, and who signs off.

For a manufacturing client, this means walking the floor and asking how a job card moves from sales order to dispatch, not asking which fields the job card form should have. For a trading business, it means asking who approves a credit limit exception today, by email, by phone, or by someone walking over to the finance manager's desk. The feature list tells you what the client thinks they want built. Discovery tells you why the process stalls, and whether building to the feature list would simply digitise the stall.

We understand how your business actually works first, then we design the system. That ordering is the entire difference between the two approaches in the table below.

What should happen, in order, before a scope is written?

A sound discovery phase follows a fixed sequence, and a buyer can ask to see evidence of each step. Skipping a step is not a shortcut, it is a gap the project inherits later.

The sequence typically runs: walk the current process end to end, with the people who do it daily, not only their managers. Name who makes each decision in that process, and what information they need to make it. Find the point where things wait, whether that is an approval sitting in someone's inbox or a stock count that only happens once a month. Check what data already exists, in what system, and in what condition, since a migration plan built on assumed data quality fails on day one. Only then draft a scope, because the scope should describe the system that fixes the delay, not the system that automates it.

A partner that proposes pricing before doing any of this is pricing a guess. How to Evaluate an India-Based Transformation Partner covers how to check a partner's decision-making before you sign anything, discovery included.

How do you tell real discovery from a feature list dressed up as one?

The tell is in what the partner asks, and who they ask it of. A real discovery conversation names specific roles and specific moments: who approves a credit note over a set amount, what happens when a delivery is short, how a production plan changes when a machine goes down. A feature-list exercise asks which modules you want and how many users will log in.

Stage	Feature-list-and-run	Real discovery phase
First meeting	Reviews your document, asks clarifying questions on features	Asks to see the actual process run, on the floor or in the system
Who gets interviewed	Whoever sent the brief, usually one manager	People who do the work daily, plus whoever approves exceptions
Output	A priced proposal matching your document	A process map, a decision list, and a scope that may differ from your brief
Timeline to quote	2 to 5 days	1 to 3 weeks, sometimes a short paid diagnostic
What changes before build	Nothing, your document becomes the spec	The scope is redrawn around where the delay actually sits

A partner that returns your own feature list with a price attached has not told you anything you did not already know. A partner worth engaging comes back with at least one thing you had not said, because they found it on the floor or in a decision no one had written down.

What should a buyer ask before signing, and who should answer?

Ask the partner to describe, in their own words, one decision in your business and who makes it. Not a feature. A decision.

"Who signs off a purchase order above $5,000 (SAR 18,750), and what do they check before approving it" is a fair question to put back to a partner after a discovery conversation. If they can answer it correctly, they were listening to the right people. If the honest answer is "we haven't got that far", the discovery has not happened yet, and any scope offered before that point is a placeholder.

For overseas buyers specifically, two further checks matter because distance removes the option of walking over to check. First, ask how the partner plans to run the discovery sessions across time zones, since live process-mapping conversations need overlap hours, not just async notes. Managing a Development Team Five or More Hours Away covers how to structure that overlap so decisions don't wait for the next working day. Second, ask who owns the discovery output itself, the process maps and decision records, if the project does not proceed. Who Owns the Code and Data When the Project Ends covers ownership terms that should be settled before any diagnostic begins, not after.

What does discovery cost, and who pays if the project does not go ahead?

A proper discovery phase is usually a paid, time-boxed engagement, separate from the build contract, and it should be priced and scoped on its own terms. At ThetaSol this is run as SCAN, a short on-site diagnostic that produces a process map and a scope recommendation, not a sales pitch for a predetermined build.

The commercial logic matters for a buyer: if discovery is free, ask what it is actually free of. A partner that absorbs the cost of proper process mapping either prices it into the eventual build regardless of outcome, or never did the mapping at all. A separately priced, separately scoped diagnostic gives you an exit point. You can walk away after discovery with a process map and a documented decision list, and take that document to another vendor if you choose. Fixed Price or Time and Material: Which Fits Your Project is worth reading alongside this, since the engagement model for the build often follows directly from what discovery finds about how stable the process is.

What happens after discovery, before the scope is final?

The scope document that follows discovery should read differently from the feature list you started with. It should name the decisions the system needs to support, the data it needs to pull from existing systems, and the point in the process it is redesigning rather than digitising. If the final scope is identical to your original brief, ask what the discovery phase changed. If the answer needs a phone call, it's not a system, and the same is true of a scope that cannot stand on its own without someone explaining what it really means.

For a longer view of the full hub on choosing a partner, see Choosing and Working with a Transformation Partner. If you are evaluating what a build actually involves once discovery is done, the custom software development service page covers how ThetaSol structures the engagement that follows.

What to do next

Before accepting any proposal, ask the vendor to name one decision in your business, who makes it, and what information it needs. If they cannot answer without guessing, the discovery has not happened, whatever the proposal document calls itself.