In-House Automation or a Specialist Partner: Which Model Fits Your Company?

In-house automation and hiring a specialist partner are usually framed as opposites. In practice, almost no SME ends up purely in one camp. The problem is reaching that middle ground by accident rather than by decision.

And the useful question is not who builds the workflow. It is who keeps it running eighteen months from now, when a supplier changes an API and nobody remembers who built the thing.

Three models, not two

In-house automation. Someone inside the company builds and maintains the workflows. It does not have to be a developer: on low-code platforms it is often someone in finance or operations who understands the process better than any IT specialist would.

A specialist partner. An external firm designs, builds, delivers and maintains under contract.

The hybrid model. The partner builds and trains, the company runs the day-to-day changes, and the partner stays available for the structural work.

Most SMEs never choose between the three. They fall into the first by default, because there is one colleague who "is good with this sort of thing". A year later the company has six critical automations, no documentation, and one person who cannot take a relaxed holiday.

What in-house automation really costs

The most common miscalculation is comparing an internal salary with a partner's invoice. They are not the same unit.

Assume a hire at €2,000 gross per month. The figure is hypothetical, so the arithmetic stays transparent. In Portugal:

• €2,000 × 14 months: €28,000
• Employer social security contribution, 23.75% under the general regime: €6,650
• Meal allowance at €6 per working day, 11 months: roughly €1,450
• Workplace accident insurance, around 1% of payroll: roughly €280

Total: around €36,400 a year, or €3,030 a month. The salary is my assumption; the 23.75% rate is the one set out in the Portuguese social security contributions code. Swap in the gross figure that fits your company and the sum redoes itself in thirty seconds.

And that is the cost of having the person, not the cost of having automation that works. In year one, a large share of that time goes into learning the tool rather than fixing processes.

Before running that calculation, it helps to have the other one: what your manual processes cost today. Without that number, every model looks expensive.

Hiring is not the easy part

Having the budget does not guarantee the hire. Eurostat data on hard-to-fill ICT vacancies shows that in 2024 only 14% of small EU enterprises employed ICT specialists, and among enterprises that did try to recruit, 57.5% had difficulty filling the roles.

Translated for whoever signs off: the "we will hire someone" plan can take six months to land, and you are competing for that profile with companies paying twice your budget.

Where a partner wins, and where it loses

A partner wins on time to first result. An internal team starting from scratch spends its first weeks deciding where to host the platform and working out why Google authentication fails in production but works in testing. A partner already lost those weeks on someone else's account.

It loses when it delivers and disappears. There are three signs that this is coming, and all of them are visible before you sign:

• System credentials are created under the consultant's personal accounts rather than company service accounts.
• The instance runs on the partner's infrastructure and the company has no admin access.
• Workflows are named "workflow 3" and "copy of workflow 3", without a line of documentation.

None of these is a technical problem. They are all contractual, and they are settled in the first meeting, not the last.

Maintenance is the invoice nobody budgets for

Automations do not decay on their own. They decay because the world around them changes: the bank alters its statement format, a supplier renames a field in a webhook, an access token expires after 90 days.

From our experience, budget 15% to 25% of the build effort per year for maintenance. That is our own estimate rather than a market figure: it assumes each external integration sees one or two meaningful changes a year, and that each one costs a few hours of diagnosis, fix and testing.

The practical question is blunt. When an invoicing workflow stops at 6pm on a Friday, who fixes it? If the answer is "Pedro, if he is not on holiday", you do not have a model yet. You have an exposure.

Three criteria that decide better than price

How often does the process change? A process that changes every month needs in-house capability. If every change has to go through a quote request, the automation drifts out of date and people quietly return to the spreadsheet.

What happens if it stops for two hours? If the answer is "nothing serious", goodwill is enough. If it is "we stop invoicing", you need a contracted response time — and that is easier to obtain from a partner than from a colleague with five other priorities stacked up.

How sensitive is the data? Clinical records, HR data and client information held under contract change the equation. Here the criterion stops being who builds it and becomes where it runs: a self-hosted instance, as n8n allows, keeps the data inside the company's own infrastructure regardless of who wrote the workflow.

The governance detail that moves the budget

One detail rarely enters the decision and should. On the free self-hosted Community edition of n8n there is no version control: whoever edits, edits in production. According to the official documentation on source control and environments, Git integration and the separation between test and production environments are available only on the Business and Enterprise plans.

And those plans carry a price. n8n's pricing page starts at €20/month on Starter, with 2,500 monthly executions, rises to €50/month on Pro with 10,000, and Business — the first tier with environments and Git — sits at €667/month billed annually.

That has a concrete consequence for the model you choose. Ask the partner which plan your instance runs on, whose name the subscription is in, and what happens to that instance the day the contract ends. It is the question that separates a partnership from a dependency.

The hybrid model, in practice

For most SMEs under 100 people, the arrangement that tends to work is this: the partner builds the two or three hard workflows and trains the team, the company owns the day-to-day changes, and a small retainer covers the structural work.

For that to hold, the handover has to include, at minimum:

• The instance running on infrastructure or a cloud account in the company's name.
• Credentials stored in company service accounts, never personal ones.
• Workflows exported and versioned, in Git or at least as dated JSON files.
• One page per workflow: what it does, what triggers it, what to do when it fails.
• Two trained people, not one. A single trained person is the same problem wearing a different name.

If you are still deciding what to hand over first, to whoever ends up building it, the list of processes worth automating helps pick the opening candidate.

The decision

Do not choose the model. Choose the first process, then the model that process justifies.

Three questions to answer this week:

1. Which process hurts most, and what does it cost per year?
2. If it changes in three months, who makes the change?
3. If it stops on a Friday night, who picks up?

Answer all three without hesitating and you already know whether your route is in-house automation, a specialist partner, or a combination of the two. Hesitate on the second or the third and the answer is probably hybrid — and the next step is writing it into the contract rather than leaving it to chance.