[TEAM SUPPLIES: confirm the firm in the post is the Merezha Prava client, and whether it may be named. Until then, no link to the Merezha Prava case study from this page.]
What happened
A law firm we build for has 36,000 clients in its app. The booking flow opened with a catalogue of practice areas. Pick your service, then book a consultation. That was the brief, and we built it as asked.
The clients could not take that first step. Pension, military, family and disability law sound alike from outside a firm. People know what happened to them. They do not know which heading it sits under.
Why a features call misses it
A kickoff call asks what the app should do. It rarely asks what a client knows on arrival. You find that gap by sitting with the firm's staff and walking through the hour before a real client calls:
- what the client says first;
- which words they do not know;
- where they stop and pick up the phone instead.
That walk-through is business-analyst work, and it belongs in discovery.
What the late catch cost
Caught in a document, the fix is one conversation. Caught after launch, it reaches the first screen and every screen wired behind it. When the post went up in August, we were redesigning that first screen.
The hours a team never spent on the wrong screen do not appear on any invoice. As Oleksiy put it, that is why the analyst role gets cut first.
Where this sits in an estimate
Our cost calculator gives a range of ±15% around a midpoint built from engineering hours per feature. The ±15% covers the features you entered. Discovery settles the ones you haven't decided. "Can clients tell the services apart?" is not a feature at all. It has no hours in the calculator, so no range can include it.
For a small app with clear answers, a call can be enough to write a proposal. When the scope is less clear, discovery comes first. What a discovery phase settles explains what it checks and how it shapes the estimate. New app and MVP development shows where it sits in a build.
One question to ask of any quote
Did anyone ask what your customers get confused by before the quote arrived? If not, ask the vendor where that question gets answered. For a second look at your own brief, book a scoping call.
The original post
As Oleksiy Kazavchynskyy posted it on LinkedIn on 11 August 2026, unchanged:
Eight years in, I can tell you exactly what a wrong assumption costs. Ten minutes in a document. Weeks once it is live. Here is one we found late.
A law firm we build for has 36,000 clients inside its app. To book a consultation, a client opens a catalogue of practice areas and picks the service they need. That was the brief, and it was built exactly as asked.
Their clients cannot tell those services apart. Pension, military, family, disability. From the outside it all reads the same. A person knows what happened to them. They do not know what it is called on a price list.
So the first step of the journey is the one step they cannot take.
Nobody finds that in a kickoff call about features. You find it by sitting with the firm and walking through what a client actually does in the hour before they call.
That is the job of a business analyst, and it is the whole reason the role pays for itself.
Caught in a document, that assumption costs one conversation. Caught in a live product, it costs the front door and the screens wired behind it. We are redesigning that first screen now.
The real output of a good analyst is not a document. It is the list of things you no longer have to build.
I cannot invoice anyone for the hours we did not spend. That is exactly why the role gets cut first.
What is the most expensive assumption anyone has made on your projects?