A large company sends over a forty-page specification. Half the requirements contradict the other half, the deadlines came out of thin air, and at the first meeting it turns out a third of the features “need to be discussed separately”. We used to sign the contract in that situation and start building. A few painful projects later, we understood that this doesn't work.
Why a raw spec is dangerous
A spec from a large company almost never reflects reality. Behind the document there is usually a legacy system, negotiations between departments, and an author who has already left the company.
Fix a budget against that document blindly and you either lose money or start cutting corners — and the client feels it. Both outcomes are bad.
The audit as a separate first stage
We moved that analysis into a separate paid stage before development. Here is what it covers:
- a review of the current architecture and infrastructure;
- separating real needs from what ended up in the spec out of inertia;
- talking to the people who will use the system, not only to the ones who sign the invoices;
- looking for risks the spec never mentions.
The client walks away with a consistent specification, an architecture, estimated milestones and a risk map. Those artifacts have value on their own: even if the client goes on to build the product with another team, they leave with a working document rather than fragments.
A word on “paid”. Charging for analysis felt awkward at first, until we noticed a pattern: free work gets treated as free. Money raises both the client's involvement and the seriousness of the conversation.
How this turns into development
After the audit we discuss a concrete plan we wrote ourselves and the client has already seen, not an abstract spec. From there we work in two-week iterations with demos, so corrections surface early rather than at final acceptance.
The structure is settled up front, so we run tasks in parallel, and on contested decisions we consult peers at other companies: an outside view has more than once saved us from a choice that looked logical from the inside and turned out to be a dead end.
What we learned along the way
An audit must not drag on: it turns into a month of correspondence and loses the point of being a fast first step.
Sometimes the honest conclusion is “you don't need development”. You lose the project in the short term and gain trust in the long term — and those clients have come back.
The approach doesn't fit everything. For a large system where mistakes are expensive an audit pays for itself; for a landing page it is overkill.
Most importantly: a paid audit is a filter in itself. Anyone unwilling to invest in understanding their own system is unlikely to see a large project through.
A question to the community
How do you enter large projects — do you take the spec as given, or run your own analysis first? And if you do, is it paid or on your own dime? We're curious to compare approaches.
If you'd like to discuss this post or share your thinking, write to sayat@silkroadtech.kz.
