Skip to content

The projects we turn down, and why we tell you early

Saying no to work we would not do well is not us being precious. It is the same judgement you are hiring us to apply to your codebase.

Written by
[Name] — Founder
Published
19 May 2026
Reading time
2 min
On
Working together

A studio of six cannot take every project, and the ones we decline follow a few clear patterns. We would rather say so here than have the conversation feel personal when it happens.

When the timeline only works if nothing goes wrong

Some briefs arrive with a date that is already immovable and a scope that only fits if every estimate lands at its optimistic end. We can sometimes help by cutting scope hard, and we will suggest that. But if the honest answer is that the date needs the plan to be perfect, we say no, because we have watched that go wrong enough times to know how it ends.

When there is no one to make decisions

A project needs someone on the client side who can answer questions about the business in hours, not weeks, and who is allowed to decide. If that person does not exist yet — if every question will go to a committee, or back to us as "you choose" — the project will stall regardless of how good the engineering is. We would be taking your money to be blocked.

When we are not the right specialists

We build web and mobile products and the systems behind them. We are not the right people for a hard data-science problem, a native game, an embedded firmware project, or a piece of deep infrastructure work. When a brief needs one of those, the useful thing we can do is say so and, where we can, point you at someone who does it well.

When the work is fine but we have no room

Sometimes the project is a good fit and we simply cannot start it when you need us to without pulling attention off work we have already committed to. Splitting the team thin to fit one more project in is how the existing projects start slipping, so we hold the line and give you a real date instead of an optimistic one.

Why we tell you in the first call

A decline in week one costs you a few days and you go find a better-matched team. A decline that arrives as a stalled project in month four costs you the months, the spend, and the restart. If we can see the mismatch early, saying so is the most useful thing we can do — and it is the same judgement you would be hiring us to apply to the code.

00Start a project

Want us to look at your scope?

Send it over — even one written by someone else — and we'll tell you what we would push back on.

Reply time
one working day
Who reads it
An engineer
Sales calls
None