Software projects rarely fail in the code. They fail in the gap between what was asked for and what was needed, and that gap is created in the first weeks, when everything is assumptions and enthusiasm. Discovery is the discipline of closing the gap while it is still cheap to close.
A real discovery phase is short and concrete: sit with the people who do the work, walk their actual workflows, find where time and money leak, and write down what the system must do in terms everyone signs their name to. Not a hundred-page requirements document nobody reads. A map of the process, a ranked list of problems, and an honest estimate built on both.
The most valuable discovery outcome is sometimes the project not happening. We have run discoveries that concluded the client needed a configuration change in software they already owned, or a smaller build than they had budgeted, or nothing at all yet. That conclusion costs a few weeks. The unneeded build it prevents costs a year.
A vendor who wants to skip discovery and start building is not saving you money. They are declining to find out what the work is before pricing it, which means someone is going to absorb the surprises later, and the contract usually says it is you.