Why I say no to some projects.

Process · 5 min read

I don't take every project that comes through the door. That's not arrogance. It's honesty. Some ideas aren't ready for design yet. Some budgets are too far from what the project actually requires. Some timelines are unrealistic in a way that would set both of us up for frustration. When I see that, I say so.

I'd rather lose a project than take one that's going to fail. Not because I don't want the work. Because I've been around long enough to know what a project looks like when the foundations aren't right. And starting anyway, hoping it'll sort itself out, is how people lose money, time, and trust in the process entirely.

When the idea isn't ready

Some ideas need more thinking before they're ready for design. That doesn't mean they're bad ideas. It means they haven't been tested enough. If someone comes to me and hasn't spoken to a single potential user, hasn't looked at what exists in the market, hasn't thought about who their first ten customers would be, the smartest thing I can do is send them back to do that homework first.

Designing an app around an untested assumption is expensive. If the assumption is wrong, the design is wrong, and the money is gone. Spending a few weeks validating the idea before investing in design is the cheapest insurance there is. I'll always recommend that path when I think it's needed.

When the budget doesn't match the scope

This one comes up regularly. Someone has a complex idea with multiple user types, integrations, admin panels, and advanced features. And their budget is a fraction of what it would take to build it properly. There are two honest responses: reduce the scope to fit the budget, or wait until the budget matches the scope.

What I won't do is take the money and deliver something half-built. A half-built app doesn't help anyone. It doesn't prove the concept. It doesn't attract users. It just burns through budget and leaves you with something you can't ship. Better to build a smaller version that actually works than an ambitious version that doesn't.

When I explain this, most people appreciate the honesty. They'd rather know upfront than discover the gap halfway through the project. Some come back later with a more focused scope. Some come back with a bigger budget. Either way, they come back knowing exactly what they're getting into.

When it's just not the right fit

Sometimes the project is perfectly valid but it's not the kind of work I do best. I specialise in working with solo founders who are building their first app. That's who I understand. That's who my process is built for. If someone comes to me with a mature product that needs a redesign, or an enterprise system that needs a team of five designers, I'll point them to someone better suited.

Saying no to the wrong projects is what allows me to say yes to the right ones. It keeps the quality high. It keeps the communication direct. And it means the people I work with get my full attention, not a stretched version of it because I took on more than I should have.

If you're wondering whether your project is the right fit, the quickest way to find out is to have the conversation. I'll be straight with you. If it's a good fit, I'll tell you exactly how the process works. If it's not, I'll tell you why and point you in a better direction. Either way, the call is free and you'll walk away with clarity.

Sources
The Focused Leader (Harvard Business Review) - Why strategic focus and saying no to misaligned work produces better outcomes.
Project Discovery (Nielsen Norman Group) - Why upfront assessment prevents project failure.

Related blog posts:

How to prepare for your first app design project →

Self-funding your app →

What is an MVP? →