After 235+ projects, the signals that predict a painful engagement almost never show up in the technical requirements. They show up in the first conversation, before a single line of scope is written.
"I'll know it when I see it" is a budget problem, not a taste problem. When a client can't articulate what they want beyond that phrase, it usually means they haven't actually decided what the site needs to do — which means "final" designs will get relitigated at every stage. We now require at least two reference sites and a one-sentence goal before scoping starts. If a client can't produce either, that's the signal, not the design brief.
Fast "yes" to every price is a warning, not a win. A client who agrees to the quote instantly, with zero questions, often hasn't budgeted for it properly and will start negotiating scope down mid-project instead of price up front. The clients who ask hard questions about what's included tend to be the easiest to work with later — they've actually thought about what they're buying.
"My last developer disappeared" is rarely about the developer. It happens, sure. But when I hear this phrase multiple times about multiple past developers from the same client, the pattern usually points somewhere else — unclear scope, constantly shifting requirements, or unpaid invoices that never got mentioned. One instance is someone else's problem. A pattern is information.
Urgency without a reason is a scope-creep predictor. "I need this live by Friday" with no explanation (no event, no launch, no deadline from their side) usually means the urgency is emotional, not operational — and emotional urgency doesn't go away once you hit the deadline. It just moves to the next request.
The best predictor of a good project is a client who can say no to their own ideas. Someone who floats a feature and then says "actually, skip that, it's not worth the cost" is a client who understands tradeoffs — which means they'll make good decisions under pressure later, not just at kickoff.
None of this is in any project management course. But if you do small-business web work long enough, you stop reading specs for red flags and start reading the client instead.
Top comments (0)