The brief is a symptom. We go and look.
Nobody buys software because of what is written in a requirements document. They buy it because of something that happens on a Tuesday, and the fastest way to find that is to watch it happen.
Thirty minutes · no predetermined package
One week, mostly reading.
No workshop, no discovery deck. The floor on an ordinary day, then every field, automation and integration in the systems that support it.
We sit with the people doing the work, on a normal day, and say very little.
We read every automation, field and validation rule, and write down what nobody documented.
We follow one record end to end, from arrival to whatever counts as finished.
We ask what the workaround is, because there is always a workaround and it names the constraint.
We find out which numbers are argued about, and who wins.
We ask what happens when someone is on holiday, which is where conventions show themselves.
A written finding, whether or not you continue.
What people ask about discovery.
What does discovery actually produce?
A written finding: what is broken, why the stated problems follow from it, and whether the answer is configuration, integration or a build. You keep it either way.
How long does it take?
A week for most operations. Longer where several systems hold part of the same truth and reconciling them is the finding.
Do you charge for discovery?
Yes, and it is priced as its own piece of work rather than folded into a build, so that stopping afterwards is a real option.
What if you conclude we should not build?
That happens regularly and it is a good outcome. You keep the finding, which is useful whoever does the work next.
Do you need access to our systems?
Read access, yes. It is the difference between describing what you were told and describing what is there.
Can our team do this instead?
Often. The hard part is not the reading — it is being willing to write down what you find.