Once a business decides to automate something, the next question arrives quickly: who should do it?
The labels are blurry. Consultants build things. Agencies give advice. Freelancers run small agencies. Platforms market themselves as “no developer needed”. The useful question is not what someone calls themselves. It is what they are responsible for.
What does each option actually take responsibility for?
Doing it yourself
Your team chooses the tools, builds the workflow, tests it and maintains it. No-code automation platforms such as Zapier and Make connect common business applications through a visual builder, and both now offer AI steps inside workflows. For a capable, curious person, that is often enough.
You are responsible for everything, including what happens when it breaks on a Friday afternoon.
A freelancer
Usually responsible for building a defined thing to a defined specification. Good freelancers are fast and focused. The scope tends to be the build itself; deciding what to build, and supporting it afterwards, may or may not be included.
An automation agency
Usually responsible for designing, building and often running automations, with more people and more continuity than a single freelancer. Some offer ongoing support as a service.
An AI consultant
Usually responsible for the decision before the build: where AI is worth using, where it is not, what order to do things in, and what the risks are. Some also implement. Some deliberately do not.
These are tendencies, not rules. Ask every option what they will and will not be responsible for, in writing.
What skills does the work need?
Most automation projects need some mix of:
- Process understanding: knowing what the work really involves, including the exceptions
- Integration skills: getting data in and out of the systems you already use
- AI judgement: knowing where a model helps, where it adds risk, and how to check it
- Testing discipline: proving it works on real cases, not just the demo
- Change management: getting people to actually use it
- Ongoing ownership: someone who notices and fixes problems
A simple, low-risk workflow between two well-known applications may need only the first two. A workflow that drafts customer-facing content or touches financial records needs all six.
What drives the cost of each option?
Comparing quotes is hard because they price different things. The main drivers are:
- How much discovery is included before anything is built
- How many systems need connecting, and how co-operative they are
- How much testing and review is designed in
- Whether support and changes after launch are included
- Recurring costs: platform subscriptions, AI usage, hosting
- Your own team’s time, which DIY makes easy to underestimate
A cheap build with no support and no testing is not cheaper. It has moved the cost to later.
Who maintains it afterwards?
Every automation needs maintenance. Applications change their interfaces. AI models are updated. The business changes how it works. Someone has to notice and respond.
Before choosing, ask each option the same question: twelve months from now, when this breaks, who fixes it, how quickly, and on what terms?
When is each option the sensible choice?
- Do it yourself when the workflow is simple, the risk is low, the applications are well supported by no-code platforms, and someone on the team enjoys owning it.
- Hire a freelancer when you already know exactly what you want built and you have a plan for supporting it.
- Use an agency when you want several automations built and run with continuity, and you are comfortable with them operating part of your process.
- Use a consultant when you are not yet sure what to automate, whether AI is the right tool, or how to sequence the work, or when the stakes are high enough to want an independent view.
Combinations are common and sensible. A consultant can help decide and specify; your team or a builder can implement; the same consultant can review the result.
Questions to ask before you sign
- What exactly are you responsible for, and what are you not?
- What happens if the first approach does not work?
- Which recurring costs will we pay, and to whom?
- Whose accounts will the workflows run in?
- What documentation will we receive?
- Who supports this after launch, and how is that priced?
- Can you show us something similar you have built, and say honestly how it went?
The right choice depends less on who is cleverest and more on who will still be responsible in six months.
If you are unsure which route fits, a free discovery call with MonoGrain is a conversation about the problem, not a pitch for a particular answer.