Make, Zapier or a custom solution, and who maintains it afterwards

Spend two evenings inside Make or Zapier and the conclusion writes itself: nobody needs to hire an agency for this. A trigger, three steps, done. For a good share of processes that conclusion holds, and the honest answer to plenty of enquiries is that you should click this one together yourself. It stops holding a few months later, once the workflow is part of daily business and nobody remembers why it stalls on certain orders.

Make, Zapier or a custom solution: building is the smaller half

Comparisons almost always look at the build, meaning the time until the workflow runs end to end for the first time. No-code platforms are hard to beat on that measure. A form takes a request, a module creates a record, an email goes out, and it works by the end of the afternoon.

The effort that follows comes from everything that does not match the pattern you built for: an order with two delivery addresses, an attachment announced as a PDF that arrives as a phone photo, a customer who exists twice under different numbers. As a rough estimate, the first working run is the smaller part of the total work. The rest arrives in small portions over the following weeks, which is exactly why it never shows up in a quote comparison.

So the choice between building it yourself and having it built depends less on the tool than on two things: how many exceptions the process carries, and who will look after it in two years.

When building it yourself is the right call

Some processes only get more expensive once a provider is involved. You can spot them by a few things.

There is exactly one system on each side, and both offer a documented interface or a ready-made connector. Data arrives in a fixed structure, meaning a form rather than free text in an email. The workflow has a handful of branches you can count on one hand. An error can sit unhandled for a day without anyone missing a shipment or a deadline. And someone in the building has the time, the interest and a backup colleague who covers holidays.

If all of that applies, a no-code tool is the correct answer and an external project would be a waste. That describes more cases than people expect: appointment confirmations, internal notifications, moving form entries into a spreadsheet, small reminder chains.

Where self-built workflows come apart in production

The cases worth thinking about are the ones where one of those conditions is missing. Suppose a wholesaler takes orders by email and has a scenario write them into the ERP. As long as regular customers use the familiar template, everything runs. Then somebody photographs an order sheet on the warehouse floor, somebody else corrects a quantity in a reply, a third customer orders for two branches in one message.

If the workflow fails visibly at that point, that is the cheap outcome. It gets more expensive when it completes and writes something wrong into the system, because accounting finds that weeks later. The worst version is a restart after an error that creates the order a second time.

Then there are the issues that have nothing to do with the process itself and still show up reliably. Credentials sit in the personal account of whoever built the thing. A connected system changes its interface and announces it in a developer newsletter nobody in the company reads. A plan hits a usage limit because volume grew, which was the entire point of automating.

None of that argues against no-code. It argues for pricing the running effort before the build rather than discovering it in production.

The most expensive line item is the person who built it

Self-built workflows are almost always side projects. Someone in sales support or IT assembles one between two other tasks because it was urgent. Which is why there is no documentation, no test environment and no second person who understands the logic.

While that person is around, this works well. They know every exception because they built every exception. When they change roles, take a long holiday or hand in their notice, the company is left with a process nobody wants to touch, because nobody knows what depends on it. That is the point at which a properly built workflow with a handover turns out cheaper, despite the higher purchase price.

There is a simple test. Ask a colleague who did not build it to make a small change, adding one more recipient address, for example. If they need the original author to do it, the process cannot be handed over.

When having it built is the cheaper route

Five signals point the other way, towards a built solution.

More than two systems are involved, and at least one has no ready-made connector. The process contains a judgement that cannot be written as a rule, such as reading an order out of free text or matching an invoice to a purchase order with differing line items. Volume is high enough that a small error rate creates work rather than exceptions. The process needs to be auditable because personal data or payment amounts are involved, and a click-together flow without proper logging does not qualify. Or the workflow is business critical, in the sense that a Friday afternoon outage costs somebody their weekend.

Two of these signals together are usually enough. At three or more, doing it yourself becomes the expensive option, whatever the licence bill suggests.

The middle path

This rarely has to be all or nothing. Most companies have one core process with exceptions and real money attached, plus a dozen small workflows that hurt nobody when they break.

Having the backbone built and clicking the edges together yourself is a sensible split. The built part gets documentation, error handling and clear ownership. The small workflows stay in the no-code tool, where the department can adjust them without raising a ticket. Reversing that split means paying twice: once for an external project to send appointment reminders, and again in internal overtime on the order process.

Sophera Consulting starts by sorting your processes into those two categories, builds the critical one as an agent for a fixed price, and hands it over with documentation, credentials and a walkthrough your team can work from. The entry point is free, in the automation check.

The recommendation

Answer three questions in writing before you decide. How many exceptions does the process actually have, counted across the last fifty transactions rather than estimated from memory? What happens in concrete terms if it runs wrong for three days without anyone noticing? And who changes it once the person who built it has left?

If the answers are unremarkable, click it together yourself and skip the quote. If one of the three is hard to answer, the process is bigger than the tool you were planning to build it with.