METIS LABS
We have talked clients out of projects we could have billed. Here is how we tell a problem software fixes from one it only hides, and why that call is cheapest to make in week one.
Some of our best first conversations end with us recommending something much smaller than what was asked for, and sometimes no build at all. That is an unusual thing for a software studio to put on its own website, so it is worth explaining why we do it and how the call gets made.
The reason is not modesty. Custom software is one of the more expensive ways to solve a business problem. It earns its money when the problem is genuinely yours, when it repeats often enough to matter, and when the fix has to fit the way your people actually work. It is a poor deal when the real issue is a process nobody has agreed on, a decision nobody has made, or a tool you already pay for and do not use. Building in those cases does not remove the problem. It wraps it in code, makes it harder to change, and adds a maintenance bill on top.
None of that means walking away. More often it means the first phase of the work is not development at all.
Three problems software does not fix
A process no one has agreed on yet. If two departments disagree about who approves an invoice and at what amount, a build does not settle that. It takes the disagreement, freezes it into a workflow, and hands you a change request every time someone objects. The honest fix is a decision, made by a person with the authority to make it, written down where both teams can see it. That costs an afternoon. Automating the argument costs a quarter, and you still have the argument.
A tool you already own. We have sat in meetings where the request was a custom reporting dashboard and the numbers were already sitting in a standard report inside the ERP, two clicks away, that nobody had been shown. Sometimes the gap is training. Sometimes it is a module that was bought and never switched on. Either way, paying twice for the same capability is not a strategy, and we would rather point at the thing you have than sell you a second one.
A volume problem that is not really there. Automation pays back on repetition. If a task runs eleven times a month and takes twenty minutes, that is under four hours, and no build recovers its cost against four hours. A clear checklist and a good template will beat custom software on that job for years. The interesting question is never could this be automated. Almost anything could. The question is whether the repetition is big enough to pay for the automation, and often the arithmetic answers it before we do.
How the call gets made
It starts with the same question we ask on every project: what is this costing you now? We ask for that baseline before we ask for requirements, because a requirement list tells us what someone already decided to build, and a baseline tells us what is actually wrong. It is the same discipline we wrote about in Set the number before you write the code. If we cannot put a rough figure on the problem, there is nothing for software to improve and nothing to hold us to later.
Then we ask what the smallest thing is that would move that figure. Sometimes it is software. Sometimes it is a decision, a settings change, a template, a supplier conversation, or one person's afternoon. We work down that list from cheapest to most expensive, and we only get to building something when the cheaper options have been ruled out on the record rather than skipped.
Four rules we hold to while we do it.
We put a price on doing nothing. If the cost of the current mess is smaller than the cost of fixing it, that is a real answer and you deserve to hear it.
We name the cheaper non-software version out loud, including what it would cost. If a two-week process change gets you 80% of the benefit, you should be able to compare it against a build with both numbers in front of you.
We separate the problem from the request. A client asks for a customer portal. The problem is customers ringing up to ask where their order is. A portal is one answer. An automated status update might be a tenth of the price and fix the same phone calls.
We say when we are the wrong shop. Some problems belong to an accountant, an ERP consultant, a lawyer, or a recruiter. Pretending otherwise wastes your budget and our reputation.
What saying no costs us
It costs revenue in the month it happens. We are not going to pretend that is comfortable, and we are also not going to pretend it is charity. Two things make it worth it.
The first is that these conversations come back. People remember the studio that told them not to spend money, and they come back with the project that genuinely needs building, usually with a decision-maker already convinced. That is a much better project to start.
The second is that a build resting on a problem software cannot fix goes badly regardless of how well we execute it. The scope moves because the underlying decision was never made. The metric does not shift because the metric was never the real issue. Then it becomes a difficult six months, a disappointed client, and a case study we would have to leave out of the ones we open up on our work page. The Shopify integration we opened in May took six weeks because by the time we started there was exactly one thing to fix and a number attached to it. Projects are short and calm when the problem was named properly. That clarity is worth more to us than the invoice we turned down.
Run the test on your own project
If you are weighing up a build right now, you do not need us to run this check. Three questions get you most of the way.
Has someone with the authority actually decided how this should work, or would the software be deciding for them? Does a tool you already pay for do this, or do part of it? Does the task happen often enough that automating it pays for itself inside a year?
If any of those answers is no, that is not a reason to shelve the project. It is the first phase of it. Mapping how the process actually runs today, making the decisions nobody has made, agreeing who owns which step and what happens to the exceptions: that is real work, it takes days rather than months, and it is the cheapest part of the whole thing. Done first, it shrinks the build, removes half the change requests before they are written, and gives us the number to aim at. Skipped, you meet it again later, at a worse moment, priced in developer days.
That groundwork is work we do with you, and it is often where we start. Sometimes it ends with a short, sharp brief and a build that is smaller than the one you walked in with. Sometimes it ends with a process that simply works, and no software at all. We are glad to be paid for either, because both are far cheaper than the version where nobody asked the question.
Open a conversation
Tell us what the problem is and what it is costing you. If the foundation needs laying before anyone writes code, we will start there and say so. If software turns out not to be the answer at all, you will hear that too, and you will hear why. Either way you will know within a week, and an hour spent getting that right beats a quarter spent delivering the wrong thing well.