Saying no
"How we decline projects that don't fit our stack, capacity, or budget."
Why this exists
Taking the wrong project ruins focus and burns out engineers. Saying no is our main quality control tool. We reject work that fails qualification so we can keep building good systems.
Operational Flow
Identify the mismatch: Pinpoint why the project fails, like low budget or legacy tech.
Draft the response: Write a short, direct email stating we cannot take the project. Skip defensive details.
Suggest alternatives: Recommend other agencies or platforms that might fit better.
Deliver the decision fast: Send the rejection within 24 hours of finding the mismatch.
Log the outcome: Save the lead details and rejection reason in Notion to improve future screening.
What good looks like
- Sending a two-sentence rejection for a WordPress site so we can focus on Astro projects.
- Declining a toxic client early and saving the team from months of bad meetings.
- Getting a thank-you from a rejected prospect because we sent them to a good freelancer.
What NOT to do
- Don't stall for weeks because you feel awkward saying no.
- Don't sign a client hoping they'll fix their behavior or tech stack later.
- Don't write long, apologetic emails. Keep the rejection clean.
We used to say yes to everyone because we feared running out of money. We once built a React Native app for a client who called at midnight on Saturdays to complain about button padding. It was miserable. We learned that accepting bad clients leaves no room for clients who actually respect our boundaries and standards.
Saying no shows we value our sanity and code quality over a quick paycheck. Decline bad fits quickly and don’t look back.