A mission is judged before it starts. Not on the technology asked for, but on the clarity of the decision underneath and the team's ability to carry what we build together.
I am often judged on what I build. I judge myself first on what I agree to build. A badly chosen mission costs more than any technical debt: it commits time, a reputation, and a team's trust.
The filter is not technical
Technical difficulty almost never worries me. What I look at is the clarity of the decision behind the request. A leader who knows why they are building, what they refuse, and what they are ready to trade off gives a solid foundation. A vague intent produces a vague system, whatever the quality of the code.
I look for three signals. A decision that can be stated in one sentence. A named owner on the client side, able to decide quickly. And a real problem, not a solution already chosen that I am only asked to execute.
What I refuse to carry alone
A mission where I would be the only one to understand the system is a bad setup, for the client as much as for me. I design so the team can take over. If there is no one to take over, or no will to learn, the deliverable becomes a dependency, not an asset.
Saying yes commits both sides. I prefer an honest framing that surfaces a disagreement early to a fast start that digs it up at the worst moment. The best time to align expectations is before day one.