Insights
April 29, 20263 min

Whywesaynotoprojects

We believe the most important decision we make as a software company isn't which projects we take — but which ones we say no to. It might sound counter-intuitive to put on our own website. But it is at the core of how we work.

The easiest business model: say yes to everything

Most consultancies say yes to almost anything that walks in the door. It is understandable — salaries have to be paid, and a customer in hand is worth two in the bush.

But it leads to problems. Projects take longer than expected. The customer doesn't get the value they were hoping for. Both parties get frustrated. And the software often ends up shelved or rebuilt by someone else.

We have chosen a different path.

We say no when WordPress is the right answer

If you need a simple website with information about your company, and you are never going to build more on top of it — then WordPress, Squarespace, or for that matter a simple template, is often the right call.

We make money building custom software. But we won't sell a Tesla to someone who needs a bike. That ends with an unhappy customer, and we would much rather be honest from the start.

We say no when the customer isn't ready

Sometimes a customer comes in wanting everything built at once. A complete system, ten integrations, every feature they have dreamt about for two years. Right now. As fast as possible.

That is where we often pull the brake.

In our experience, the best systems get built in stages. Start with what is most valuable, learn from the use, and expand from there. When customers push to ship everything at once, we typically end up building features they never use — while overlooking the ones they actually needed.

If we can't agree on a phased approach, we are probably not the right match.

We say no when the scope doesn't match the value

Sometimes a customer asks for a feature that would take 80 hours to build — and might save them 30 minutes a month.

That math doesn't add up. We say so out loud.

That doesn't mean we don't want to earn the money. It means we don't want to build something that doesn't actually create value for the customer. That is the fast lane to a customer who, six months later, thinks: "What did we actually pay for?"

We would much rather suggest a simpler solution that solves the problem for a tenth of the price — even if it means we sell less in this round.

We say no when the chemistry isn't there

Software projects are collaborations, not transactions. We typically sit in close dialogue with the customer for weeks or months. If we sense early that we can't find a good rhythm — that communication is hard, or that expectations are fundamentally different — it is better for both parties to say so right away.

We have turned down projects that would have been financially good for us, because we knew the end result wouldn't make anyone happy. We have never regretted it.

What it means for you as a customer

When we say yes to working with you, it means:

  • We have judged that the project is right for you — not just profitable for us.

  • We believe we can deliver real value within a frame that makes sense.

  • We expect to be able to work well together, and be honest with each other along the way.

It also means you can trust the advice we give you along the way. When we recommend a particular technology, a particular architecture, or a particular order — it is because we mean it. Not because it gives us more billable hours.

Our position

We believe fewer, better projects beat more mediocre ones. That the hardest — and most important — decision is to say no to the wrong work, so we have room for the right work.

That isn't a luxury. It is discipline. And it is how we make sure that two, five and ten years from now, we still have customers who recommend us on.

It is the only business model we believe in for the long run.