We are a workflow automation agency, so we have an obvious stake in this. It is also why the guide is worth writing: in practice we see the same label used by firms doing very different work, from configuring an automation platform, to building custom software, to starting with the process itself. What follows is our way of thinking about that, not an industry standard.
The differences matter more than the pricing. Hiring the wrong kind is how you end up with an elegant automation sitting on top of a process that should have been changed instead.
Three kinds of firm, one job title
None of the three is wrong. They are answers to different questions, and the mismatch is what costs money.
- The tool implementer. They know one platform deeply and will configure it well. When the process fits the platform, this is often the shortest route to something working. When it does not, the work moves into custom logic and workarounds, which removes much of that advantage.
- The generalist development shop. They will build whatever the brief says. Strong when you already know exactly what you want, risky when the brief itself is the thing that needs questioning.
- The firm that starts with the process. They spend the first part of the engagement understanding how the work runs before proposing anything, and some of what they propose will not be software. That discovery costs time upfront, and it is unnecessary if all you need is a known integration between two standard tools.
Five questions that separate them
- Ask for a time they decided something was not worth automating. What they say tells you how they decide what gets built at all.
- Who owns the accounts, the code, and the automations when we stop working together? Get the answer before signing, not at the end.
- What breaks when the other system changes? Someone who has run integrations in production should be able to say what they monitor, which upstream changes have broken things before, and what happens when a sync fails.
- Tell me about one that went wrong. The useful version of this answer includes what they changed afterwards.
- Will you work inside the tools we already run, or move us onto yours? Both can be right. You want to know which conversation you are having.
What each pricing shape rewards
Fixed scope works well when the requirements are genuinely known in advance. When important ones are still being discovered, every new finding risks turning into a scope discussion.
Day rates work better when there is real uncertainty in the scope, but you have to stay involved, because nothing external limits the total. Retainers are easiest to justify once there is a live system to maintain and improve; before that, a retainer needs a very clear purpose and output.
Be careful with pricing tied to hours saved. It sounds aligned, but it can reward automating the easiest hours to measure rather than the work that creates the most value, and you will spend part of the engagement arguing about the baseline.
When you should not hire anyone
- You need one connection between two mainstream tools. Check the native integrations and the usual no-code connectors first: if one already covers the workflow reliably, there is no project to pay for.
- An off-the-shelf product already does this and your objection is the subscription. Compare the subscription with a build plus its maintenance before deciding the build is cheaper.
- Somebody internal is already close to solving it and mainly needs technical direction. Buy the targeted help rather than outsourcing the whole problem.
- The process is about to change. There is usually value in waiting, rather than encoding decisions you already know are temporary.
Where we sit
Our own work sits closest to the third model. Engagements start with the process rather than a platform, and the first deliverable is usually a map with numbers on it rather than working software.
For Mutualys, a health insurance group, that led to an in-house CRM and a WhatsApp chatbot. Their lead handling was spread across email, phone notes and spreadsheets, and the off-the-shelf options we looked at did not fit the way they qualified and followed up a lead. An engagement that ends in a configuration change rather than a build is an equally acceptable outcome for us.