It is the first question we get, and the only one for which an honest figure is impossible before we have looked at the work. What we can do is explain what makes the cost vary, and how to assess whether the project is worth it before you invest.
A vendor who gives you a firm price after a fifteen-minute call is probably selling you a generic tool. A vendor who refuses to talk money before six weeks of “discovery” isn’t helping you either. The truth is in between: the cost depends on a few factors we can name, and a good project is structured so that you know early enough whether to continue.
The six factors that set the bill
- The scope of the process. Automating one specific step of a task is nothing like equipping a whole role. The narrower and clearer the scope, the more predictable the cost.
- The state of the data. If the information already exists, well filed, in a readable format, the project moves fast. If it is scattered across emails, spreadsheets and the memory of two employees, part of the budget goes to putting it back in order. This work is rarely visible, but it is sometimes half the project.
- Integration with what you have. A tool that lives alongside your systems is simple to build and hard to get adopted. A tool plugged into your email, your ERP or your shared files takes more work, but it is the one people actually use.
- The level of validation required. The more an error costs, the more points of human validation we add, and the more design the system needs.
- Compliance. Personal information, health data or sector constraints add scoping and documentation work, which is better budgeted at the start than discovered at the end.
- Adoption. A system adopted at 30% returns nothing. Training, support and ease of use are cost lines, but they are also the ones that decide the outcome.
Why we don’t sell a monolithic project
The surest way to limit risk is never to commit the whole budget at once. Our standard structure comes down to four pieces: a diagnostic to know where to invest, fixed-price implementation in batches, the first of which is small and gets into production quickly, managed support on a monthly agreement, and training if adoption is an issue.
This split has an important consequence: you see a real result before committing to the next step. If the first batch doesn’t deliver what was promised, you stop, and the loss is limited. If it is a success, the second batch rests on numbers, not on a presentation.
How to assess the return before deciding
The basic calculation is simple, and you do it with your own numbers:
- How many times a week is the task done?
- How long does it take, measured rather than estimated?
- What is the loaded hourly cost of the people who do it?
- What share of the time can reasonably be recovered?
An example from a published case: at 3D Coupe, we estimate about thirty parts a week, with 43.9 minutes recovered per part. That adds up to nearly 22 hours a week, or more than 1,100 hours a year, on a task nobody enjoyed doing. From there, any SME can set the hourly cost of those people against it and judge whether the order of magnitude justifies a project.
One point of caution: recovered time is not money saved until that time is reassigned to something more useful. In the 3D Coupe case, it is the programmer who goes back to the projects that truly need their expertise. A gain that isn’t reassigned to anything remains a nice statistic.
The costs people forget
Beyond implementation, three items often slip under the radar. Model usage (the API calls), which is generally modest compared with the human time replaced but needs watching as volumes climb. Support, because a system in production evolves: a business rule changes, a vendor modifies its format. And governance: who validates, who corrects, who decides when to stop.
What if I pick the wrong project?
That is precisely the role of the diagnostic. In the 3D Coupe case, twenty-two options were assessed before choosing one. The one we would have picked by instinct was not necessarily the same. A diagnostic costs less than a bad project, and it leaves you a plan even if you decide not to launch anything right away. Depending on your situation, part of the diagnostic may also be covered by financial aid: we talk about it in our article on funding.
To see what is currently available, read our funding overview →
Where to start
The online diagnostic questionnaire and the 30-minute exploratory meeting are free: they exist to see whether a project makes sense before you invest anything. The full diagnostic, on the other hand, is a paid service, with an on-site visit and team meetings. At the end, you know where to invest, in what order, and at what order of magnitude of effort.
What this article argues, we put into production for a client. The case walks through what was built, how, and what changed.
