Most projects arrive with a vague brief. Someone describes what they want in three sentences, and the first month of the engagement is spent turning that into something a team can build against.
Occasionally the opposite happens. A client arrives with a plan that is detailed, internally consistent, and clearly the product of real work — a scope broken into phases, a chosen stack with reasoning behind it, acceptance criteria written as testable statements rather than adjectives.
That is a better position to start from. It is also a more dangerous one, and I did not appreciate how much until I had to raise four objections to exactly that kind of document.
Why a good plan is harder to argue with
A vague proposal gets questioned by everyone who reads it. Nobody trusts three sentences, so the assumptions inside it stay visible and get challenged early.
A detailed proposal gets trusted, because the detail itself reads as diligence. If someone has priced their storage decision, inventoried their content, and written acceptance criteria, the natural assumption is that the rest of it has been thought through to the same standard.
Usually most of it has been. That is the problem. The parts that were not thought through are sitting inside a document where everything else was, and they inherit the credibility of their surroundings.
Every assumption in the plan I was handed was stated clearly enough to be checked. None of them had been. So I read the vendor documentation for every platform the plan named, and put arithmetic against every cost it assumed.
Four things would not have survived contact with production. Each one would have surfaced mid-build — at the first heavy job, at the first test on real hardware, at the first invoice, at the first performance audit. And each one would have arrived looking like a delivery failure, not like a shared assumption both sides had missed.
The part nobody prepares you for
Finding the problems took a few days of reading. That was the easy half.
The hard half was this: the client had just spent considerable effort producing a plan he was proud of, and I was about to tell him four parts of it were wrong. Handled badly, that meeting turns into a defence of the document, and the build proceeds on the original plan with a client who now trusts my judgement less than he did that morning.
Being right is not the same as being useful. A correct objection that does not land changes nothing.
Three things that made it work
I asked to meet, rather than sending a list.
My instinct was to write back with the four issues, each with its evidence. I did not, because written disagreement invites a written defence. The document comes back with counterarguments, and now two people are defending positions instead of solving a problem.
In a conversation you can show the arithmetic and watch which parts land. You find out in real time which objection he had already half-suspected and which one is genuinely new. That changes how much time each one needs.
I listed everything I was accepting first.
Before any of the disagreements, I went through what I was adopting from his plan unchanged — which was most of it. His storage decision was correct and I said so, along with why: the reasoning behind it was the strongest argument in the document.
This was not a softening tactic. It was accurate, and accuracy is the point. Four objections arriving on their own read as reflexive — the new person establishing that they think differently. The same four arriving after a full accounting of what was right read as considered. He could see I had actually engaged with the document rather than skimmed it for things to correct.
I opened with my own side's mistake.
One of the four was a deployment platform that had been agreed in an earlier round, before I joined. I could have raised it as a finding. Instead I opened that section by saying it should have been caught then.
That reframed the whole conversation. We were not in a meeting about his errors. We were in a meeting about assumptions that had gone unchecked on both sides, which is what it actually was.
The fourth thing: saying "I don't know"
There was one item I could not resolve. Two payment products needed to be available for an entity in his country, and I could not confirm it from public documentation.
The tempting move is to assume the reasonable answer and move on. One unverified detail in a long document does not feel like a risk.
I flagged it instead — as an open item, with a named owner, a deadline, and the fallback plan if the answer came back no.
Two things came out of that. The practical one: if the answer had been no and I had assumed yes, it would have surfaced at the exact milestone that depended on it, weeks later, as my failure. The other one mattered more. Marking one item as uncertain tells the client the others are not. If everything in a document sounds equally confident, the reader has no way to tell what has been verified and what has been assumed. The "I don't know" is what makes the rest of it credible.
What I would take from it
Every architectural change was accepted in that meeting, and the one acceptance criterion that could not be met was rewritten rather than dropped.
I do not think that outcome came from the quality of the analysis. The analysis was not clever — it was reading documentation carefully and doing arithmetic before agreeing to things. Neither is difficult, and both get skipped constantly, because at proposal stage nobody is being paid to do them yet.
What the outcome came from was the shape of the disagreement: in person rather than in writing, accepting loudly before disagreeing specifically, and naming my own side's error before naming his.
Disagreement is a delivery skill, not a technical one. The technical part tells you that something is wrong. It tells you nothing about how to say it in a way that changes what gets built.