HasnainWhy I Turn Down Projects Without a Clear Problem Statement
Not every project that comes my way gets a yes, and that's intentional. The clearest predictor of whether an engagement goes well isn't budget, it's whether the person I'm talking to can describe the problem they're solving in one or two sentences.
## What a vague brief actually costs
When a project starts without a clear problem statement, the ambiguity doesn't disappear, it just moves downstream. It shows up three weeks in as scope creep, or two months in as a product that technically works but doesn't solve anything anyone actually needed solved. By then, the cost of that ambiguity is measured in real time and real money, not just a slightly longer discovery call upfront.
## What I actually listen for
- - Can you tell me who specifically struggles with this problem today, and how they cope without your product
- - Do you know what "done" looks like for version one, or is it open-ended
- - Are you looking for a partner who pushes back on scope, or someone to execute a fixed spec exactly as written
None of these questions are about budget. They're about whether we're both going to be working from the same understanding of what we're building, which matters more than almost anything else in a scoped engagement.
## This isn't about being difficult
Saying no to unclear briefs isn't gatekeeping, it's protecting both sides from a bad outcome. A founder with a fuzzy idea isn't a lost cause, they usually just need a structured discovery conversation before any code gets written, not during it. I'm glad to have that conversation. What I try to avoid is starting a build while the target is still moving, because that's how good developers end up building the wrong thing very well.