Saying no is the work.
A bad project takes the same calendar time as a good one. Both fill the team's working hours, both occupy the same project slot, both deny that slot to a different client. So a yes to a marginal project is also a no to a strong one we haven't met yet.
The math is even worse than that. A bad project leaks. The engineering is annoying, motivation slumps, code quality drops by a half-grade, the deadlines slip, the other concurrent projects pick up the slack. Bad projects are expensive in ways the timesheet does not show.
The five filters.
Every inbound brief goes through five quick filters. Three fails and we say no. Two fails and we have a hard conversation.
Engineering depth. Is there something here that genuinely needs us? If the answer is "a WordPress site plus a contact form", we recommend an agency.
Decision maker. Is the person we're talking to the one who can say yes and pay invoices? Three layers of middlemen is a yellow flag; four is a red one.
Honest scope. Does the brief describe what they want, not what they think they should ask for? If we ask "why this feature?" three times and don't get past surface answers, it's a no.
Realistic timeline. Anyone who says "we need it in six weeks" for a six-month build is telling us something useful about how they'll manage the rest of the project.
The room. If a client treats engineering as a cost centre to be squeezed — not as the thing that makes their product good — that relationship breaks under load. We pass.
What wrong fit looks like.
Wrong fit usually looks reasonable on paper. The budget is fine, the timeline is fine, the tech stack is fine, the client is polite. The tell is in the second conversation: they cannot answer questions about their users without consulting a deck, they describe the problem in solutions ("we need a microservices architecture"), and they are gently shocked when we suggest scope cuts.
We have learned the hard way that fixing this in the SOW does not fix it. The way the relationship starts is the way it stays.
What right fit looks like.
Right fit is much rarer and easier to spot. The client has a specific operational problem that's costing them measurable money. They can describe their users in concrete detail. They have already tried the obvious solutions and can tell you exactly why they failed. They know what they don't know.
Those engagements are a joy. The work is interesting, the client respects the trade-offs, the software gets used the day it ships, and a year later it's still running fine. We aim for ten of those a year — three or four concurrent at a time — and turn down everything else.