Agency, freelancer or in-house team for automation: how to decide

No type of provider guarantees good automation on its own. To decide, look at three things: what happens if it fails, who will maintain it and what it will cost to run once it's delivered. A freelancer can handle a well-scoped project; an agency can bring several specialties at once; and an in-house team starts to make sense when building and maintaining workflows is recurring work. In all three cases, ask for the same testing, documentation and exit terms.

The three criteria

1. What happens if it fails. The risk depends on impact (an internal notification is not a payment or a customer left without a reply), on the volume that runs through the workflow and on your ability to spot the failure and reprocess whatever got stuck halfway.
2. Who will maintain it. This weighs more the more the workflow depends on others, the more critical it is and the more often your processes or the tools it connects change. Whatever the model, you need someone in-house who decides scope, validates results and prioritizes changes.
3. What it will cost to run. The build price is only one line item. The full list to compare is further down.

The three models in short

These are tendencies, not rules. Documentation, testing and continuity depend on what you agree in the engagement, not on the type of provider.

1. Freelancer or independent consultant. Usually brings direct contact and a fast start on well-scoped projects. Common limit: one person's capacity and availability.
2. Agency or external team. Usually brings several specialties at once and capacity without hiring. Common limit: more coordination, and the knowledge stays outside unless it's documented and handed over.
3. In-house team. Usually brings business context and direct control over every change. Common limit: the time it takes to hire and train, and dependence on whoever built the workflows if they aren't documented.

Hold all three to the same requirements: a system owner inside your company, testing before go-live, documentation, a maintenance plan and exit terms. With an in-house team, the exit is the handover when someone changes roles or leaves.

Two scenarios with different risk

Picture two projects at the same company.

Web form, CRM and a heads-up to sales. Every request from your website creates a contact in the CRM, for example in Attio, and notifies a sales rep. It touches three systems, and its risk depends on what happens when it fails. Risk is low if few requests come in, someone checks each week what was received against what was created and a lost contact can be reprocessed from the form itself. It goes up if the first reply to a prospect depends on that notification, if volume is high or if nobody would notice a gap. In the low-risk version, someone on your team or a freelancer with a fixed-scope engagement can handle it, as long as it includes an error alert to a named person and a way to reprocess.

Closed deal, invoice and project kickoff. When a deal moves to won, the invoice is generated, the customer is notified and the kickoff tasks are created. Here there are dependencies: if the invoice fails, the notification shouldn't go out; if someone renames a CRM field, everything downstream breaks. The impact reaches billing and customers, and reprocessing means being able to rerun a step without duplicating the invoice. What decides isn't the type of provider but who can test with real cases before go-live, document the dependencies, respond to incidents and ship changes at the pace your process changes.

Total cost: which line items to compare

Ask for each line item separately, even if one of them is zero, and compare the total, not the rate:

1. Discovery: understanding the process and locking the scope.
2. Build.
3. Tool licenses.
4. Testing.
5. Support and incident response.
6. Later changes.
7. Team training.
8. Exit cost: handover to another provider or to your in-house team.

For an in-house team, also count the hours of the people who build and maintain it.

Six questions before you sign

Ask them the same way of a freelancer, an agency or your own team, and get the answers in writing.

1. Whose name are the accounts in? Your company's, with admin access for you and delegated permissions for whoever builds. Passwords are not a deliverable.
2. What exactly gets delivered? Workflows, an integration inventory (what connects to what, and with which permissions), documentation and a test log, in a single list.
3. How is it tested before go-live? Which cases, which data and who signs off.
4. How are failures detected and who responds? An error alert, a name or a channel, and what counts as urgent.
5. Who ships changes and how do you request them? This matters most if your processes or tools change often.
6. What happens if the relationship ends? A handover plan for access, workflows and documentation. Check the agreement for ownership of what's built and for who holds the licenses.

If you need specific certifications, data residency or audits, ask the provider for evidence before you sign.

How we work at The Optimal Flow. In all our projects, tool accounts are created in the client's name, we work through delegated access to those accounts and the documentation of what we build is delivered to the client and stays in their name. Since the accounts are already theirs, the handover doesn't require moving anything: the client keeps the accounts and the documentation and manages the permissions they delegated to us. The rest of our approach is on our page about systems, automation and applied AI.

When you don't need outside help

1. A well-scoped automation that someone on your team can build and maintain, with an error alert and a way to reprocess. Build it in-house.
2. The process isn't defined or has no internal owner. Sort it out and name the owner first; automating it before that only speeds up the problem.
3. The automation is part of your product and you have engineering. Let your team build and maintain it.
4. You want the capability in-house. If you'd rather keep the workflows in-house, you can train your team: there's automation training for companies, a course on process automation with AI and another on automation maintenance in tools such as Make, n8n or Zapier.

FAQ

Can you combine models?

Yes. For example, someone in-house decides what gets automated and why, and someone external builds it. That person keeps the context even if the provider changes.

Who should the system owner be?

Someone who knows the process and has time to validate results and prioritize changes. They don't need to know how to build the workflows.

Next step

If your case looks like the second scenario (several tools, impact on billing or customers, frequent changes) and you don't have the capacity to maintain it in-house, book a call and come with this question in mind: which workflow would hurt you most if it failed tomorrow, and who will maintain it six months from now?

Author: Juan López Parra, COO · Automation & Sales Lead. Published: October 21, 2026.