The fight that starts every time a client says "this should have worked differently"
You build exactly what the brief said. You send it over. The client looks at it and says "this isn't quite right, it should work more like this."
And now you're in the worst conversation in client work.
You say it's a change request. They say it was obviously included. You both go back to the brief, and you find one vague sentence that somehow proves both of you right. Nobody is lying. They described what they could picture in their head. You built what was actually written down. The gap between those two things just became your problem.
So now you pick your loss. You build the change for free and eat the hours, or you invoice it and watch a good client start reading your emails twice, wondering what else is going to cost extra.
I've been on both sides of this more times than I can count. And every single time, when I trace it back, the fight didn't start when the client asked for the change. It started weeks earlier, in a kickoff where everyone nodded and nobody actually pinned down what "modern" or "clean" or "simple" meant in concrete terms.
The intake form doesn't fix it. Clients fill out three fields and leave the rest blank. The kickoff call doesn't fix it either. People agree to everything in a call and remember it completely differently a month later. The problem isn't that clients are difficult. It's that they genuinely don't know what they want until they see the wrong thing built.
I got tired of this, so I built something to deal with it. It's called ReqBrief. Instead of sending a client a form to fill out alone, you send a link to a short AI interview that actually asks follow-up questions when an answer is vague. At the end you get a structured brief you can scope and quote from, so when the "this should have worked differently" moment comes, there's an actual document both of you agreed to.
There's a live demo on the landing page where you can play the client and see how it works without signing up: reqbrief.com
Genuinely curious though, before the product stuff: how does everyone else here handle this exact moment? When the client pushes back and calls a change request "something that was obviously included," what actually works for you?
I think you've identified the real problem. Most scope creep doesn't come from bad clients—it comes from assumptions that never got written down. By the time someone says "that's not what I meant," both sides genuinely believe they're right.
Exactly, and the "both sides genuinely believe they're right" part is what makes it so hard to resolve. It's not a negotiation where someone is trying to get one over on the other. It's two people who had different pictures in their heads the whole time and only just found out. Once it's gotten to that point, there's no clean answer. The only real fix is making the assumptions visible before anyone starts building.
That's exactly the implication I was thinking about.
I think there's one strategic business decision sitting underneath your reply that becomes much more significant as the product evolves, but I don't think I can do the reasoning behind it justice in a thread.
Happy to explain what I mean if it's useful. What's the best email to reach you on?
Appreciate it. I'd rather keep it in the thread if you don't mind, partly because other people reading might benefit from the same point. If it's something that genuinely can't be said in public that's fair enough, but I've found the most useful insights usually survive being said out loud. What's the rough shape of it?
The rough shape is this:
The assumptions themselves aren't the strategic decision.
The bigger question is whether your product is ultimately helping people document assumptions, or helping teams establish a shared understanding before assumptions ever have the chance to diverge.
Those sound similar, but they lead to very different positioning, product decisions, and even different customers over time.
That's why I thought there was a much bigger business question hiding underneath your reply.
The way I see it right now: the interview happens before anyone starts building.
The client is talking, not reviewing a document. So the assumptions don't get written down after the fact, they get surfaced in the moment when the client is still thinking out loud.
Whether that counts as "establishing shared understanding" or "documenting assumptions" probably depends on which side of the conversation you're on.
But you're pointing at something real. If the product drifts toward being a documentation tool, it becomes a different business. I'm deliberately keeping it upstream of that.
What's your read on which one agencies would actually pay for?
That's a really good question, and I actually have a fairly strong view on it.
I don't think I can explain the reasoning properly in a thread without oversimplifying it, because the interesting part isn't which one agencies would pay for—it's why that answer quietly changes what kind of company you're building.
What's the best email to reach you on? Happy to walk you through my thinking there.
I appreciate the offer, but I'd rather keep it here if that works.
You've already laid out the core of it pretty clearly: documenting assumptions vs. establishing shared understanding before they diverge. That's a real distinction and I've been thinking about it since you first raised it.
If there's a specific reason the reasoning only works off-thread, I understand. But if it's something that can be said out loud, I'm genuinely curious to hear it here.
This comment was deleted 3 months ago