An automation supplier earns money from things being automated. That is an obvious conflict of interest and there is no point walking around it: the bigger the scope, the bigger the invoice. So it is useful to know under what circumstances such a supplier says no, and whether they ever say it at all.
Below are four cases from the last two years where we said it. In two of them it meant a smaller job, in one of them no job at all.
1. When an off-the-shelf service already does it
Summer 2026, a manufacturing company. The brief was to connect the warehouse system to accounting and automate document intake. On 27 July 2026 it turned out that one of those systems had no usable interface for document intake, and the client asked of their own accord whether software that clicks through the interface on a person's behalf would solve it.
We could have built that. Instead, on 29 July 2026 we checked a competing off-the-shelf service and wrote to the client that it works on a different principle and might suit them better - even though this removed part of the scope from our own proposal. The client did indeed solve that part elsewhere, and the brief narrowed.
The end of the story is part of the point: we did not win the job. On 19 August 2026 the client chose a different supplier and wrote that our proposal had been on the final shortlist right to the end and that the decision between the last options had been close. That sentence about the off-the-shelf service did not cost us the job, but if it had, we would say it again. A customer for whom you build bespoke something they could have bought ready-made finds out in the end - and by then they no longer remember it was their own idea.
2. When the automation is slower than a person
February 2026, our own product Jobsi. We wanted to add an assistant to the staffing-agency system that answers questions against the live database. The prototype worked. But an answer against the full database took so long that it was quicker to look the same thing up by hand.
The decision came on 27 February 2026 and it was short: a feature that is slower than the manual way is not worth releasing. It was not that it could not have been polished. It was that polishing it would have swallowed weeks that had a different priority.
This is the most typical shape of "not worth it", and the awkward part is that it only becomes visible after the first version. Which is why the first version is kept small and measured immediately, not after rollout.
3. When the automation would only prop up a missing feature
April 2026, our own tool again. We wanted the bot to be able to record meeting calls and turn them into tasks. The design ended up requiring the program to capture audio in thirty-second chunks and stitch them together, because there was no direct access to the recording.
We dropped it on 10 April 2026. Not because of the cost, but because of the nature of the construction: a prop that works around a missing feature breaks at the first change on a side you do not control. What stayed was the ordinary approach - the call is recorded the normal way and the recording is processed afterwards.
The tell for this category: the words "work around", "simulate" or "well, it can be done by" show up in the description of the solution. Sometimes that is a legitimate route and sometimes the only one available. But it always has to be said out loud that such a construction has a shorter life, and that has to be priced in.
4. When the feature should not be built at all
November 2025, a dealer in agricultural machinery. A site with a machine catalogue; the brief read like an e-shop. We looked at how that trade actually works: nobody puts a tractor in a basket and clicks through a payment gateway. The customer picks a model and phones.
On 12 November 2025 we decided not to build the e-shop layer and to make the machines an ordinary content type with a contact form. The customer saved time both on building and on running a feature nobody would have used, and the site runs to this day without carrying it. The address is tafe.cz and it is in our portfolio.
The lesson here is broader than in the other three: the most expensive automation is the one that works flawlessly and nobody needs. You do not spot it through a technical analysis; you spot it by asking how the process runs today and who sits at it.
How to work it out before you ask anybody
You do not need a quote for this. You need three numbers you already know:
- how often the task occurs (weekly, monthly);
- how many minutes one of them takes;
- how much of that is deciding, which a person will have to do anyway.
The first two multiplied together is the upper bound on the saving. The third number reduces it, and for most processes it reduces it more than expected: what can be automated is moving and checking, not deciding. Set against that not only the cost of delivery but running and maintenance too - the tools' subscriptions and the time somebody spends on repairs after every change in the connected systems.
When the difference comes out narrow, that is not a reason to do nothing. It is a reason to do a smaller piece and measure it.
Three signs it will not pay off, even when it sounds good
The process changes every quarter. Automation fixes today's shape in place. For a process that keeps moving you pay for that twice: once to build it, once to rebuild it.
There are more exceptions than rules. When somebody says "this one is different" on every second case, you do not have a process, you have a craft. What can be automated is what is the same. The rest can only be described, and the description is work you will have to do anyway.
Nobody uses the output. The cheapest saving of all: a report somebody produces every week because that is how it was set up should not be automated but discontinued. Ask whoever receives it when they last looked at it.
What we say instead
We have one sentence for this in our proposals and we mean it:
"If it turns out that a stage does not make economic sense, we will tell you straight."
The sentence comes with the method of finding out: the proposed approach is tested for viability on your real data, not on a sample case. A sample case always passes - that is what it is for.
And one thing we will not do even on request. On 28 July 2026 on one project we discussed whether to use an unofficially activated licence of a server system and save a few hundred dollars by it. We went with the licence: the customer's trading operation is meant to run through that server, and a saving that lets unknown software into it is not a saving.
Want to hear whether it makes sense in your case
Tell us which task holds you up most, how often it occurs and how many minutes it takes. We will come back either with a proposal or with the reason it is not worth it. Before you commission the work from anyone, it helps to have four things for an integration ready.
What we do when it does make sense is described under business process automation.
Write to info@lamapixel.com or call +420 775 599 009.
