A kitchen that makes twelve things makes them well. A kitchen with two hundred items on the menu is microwaving most of them, and you can taste it. The long menu isn't generosity — it's a refusal to choose, and the choosing is the whole job.
We get asked to build a lot of things, and we turn work down most weeks. Not because we're precious about it, and not because the work is beneath us — because a short list of honest noes is the only thing that keeps the yeses buildable. Say yes to everything and you become the two-hundred-item menu: technically able to do anything, actually good at nothing.
So here's the list. It's short on purpose.
What we won't build
- A strategy we don't intend to build. We don't sell a document that recommends doing the work later. If we can't follow the thinking straight into a working system, the thinking isn't ours to charge for.
- On a process nobody can describe. If no one in the building can tell us how the work actually runs today — the real steps, the Wednesday exceptions, where it breaks — it isn't ready to be automated. We'll help you map it first, or we'll pass. We won't guess and call it a build.
- Something only we can run. If handing it over means you're tied to us forever, we've built you a dependency, not a tool. Anything we ship has to keep running after we've gone and stopped answering the phone.
- The everything-platform. "Can it also do…" is how a clean build turns into a swamp. We scope one process, end to end, and we hold that line. A wishlist is not a project.
- The thing an off-the-shelf tool already does. If a R200-a-month product solves your problem, we'll name it and decline the work. Charging you to rebuild Calendly isn't a business we want to be in.
None of these are moral positions. They're practical ones. Each is a way a build quietly goes wrong, and saying no at the start is cheaper than discovering it at the end.
A firm that will build anything builds nothing especially well. The "no" is what keeps the "yes" honest.
Why the no comes first
Saying no upfront feels like leaving money on the table. It isn't. The work we decline is, almost always, the work that would have gone sideways — the project with no owner, the scope that never stops growing, the build that solves a problem the client didn't actually have. Turning it away protects the work that lands. The team that isn't firefighting a doomed project is the team that ships yours on time.
There's a quieter reason too. A clear no is a kind of respect. Stringing a prospect along through a discovery phase you already know will fail isn't kinder than telling them on the first call — it's just more expensive for them. We'd rather lose the work in fifteen minutes than waste a month of someone's budget being polite.
For the technical reader
The list above isn't posturing — it's encoded in how we scope. The same 48-hour scoping pass that prices a build is also the filter that rejects one, and these are the concrete signals that turn a scope into a no:
- No process owner. If there's no single person who feels the pain and will own the result after handover, the system has nothing to attach to and quietly dies. We screen for that owner on the first call.
- An undescribable process. If the team can't walk us through the current workflow, exceptions included, there's no specification to build against. The honest next step is a small mapping engagement, not a build.
- Scope with no boundary. A request that keeps adding "and also" is a platform, not a process. We scope the most common path end to end plus a defined escalation route for exceptions; if the request refuses any boundary, it isn't ready.
- A solved problem. If a configured off-the-shelf tool — scheduling, forms, e-signatures, a basic CRM — covers it, the right answer is the tool and an afternoon of setup, not a custom build with a custom maintenance bill.
When we say no, we try not to say it empty-handed. The usual outcome is a pointer to the cheaper tool that actually fits, or a small fixed-price spike to map the process so it can be scoped properly later. Declining the work and helping the person aren't opposites.