When not to outsource an automation (yet)

The short answer

Not every task worth automating is worth outsourcing right now. Hold off, or keep it in-house, when any of these is true:

1. The process is still changing. You will pay for every change as new work.
2. Nobody on your side will own it. It will stop quietly and stay stopped.
3. The hard part is a judgement call you have not written down as a rule.
4. It cannot run without you, because a source needs a person to log in each time.
5. A built-in feature or a template already does most of it.
6. The maths does not work once a year of fixes is counted.

None of these means “never”. They mean “not this week, not as a fixed-price build”. Most of them are fixed with a few weeks of doing the task by hand and writing down what you do.

Why outsourcing is a bet on a stable brief

A freelancer quotes what the brief describes. A fixed price, a delivery date and an acceptance test all assume that the steps, the inputs and the result will still be the same when the work is delivered.

When that assumption holds, outsourcing is efficient: you buy experience you do not have, and you get a working job in days. When it does not hold, every difference between the brief and your real process becomes a conversation about whether it is a fix or a change, and the maintenance guide is clear that a change is a new order.

So the question before hiring is not “can this be automated?” Almost anything can. It is “will the thing I describe today still be the thing I want next month, and will someone here look after it?”

Sign 1: the process is still changing

This is the one I learned the hard way, on my own automations rather than a client’s.

In early September I changed what a content pipeline produced twice in about a week, and reworked its fonts in between. Each change looked small from the outside. Underneath, the scheduled publishing step had been written for the old output, and after the first change it disagreed with the new one in several places at once. Had I simply switched the schedule back on, it would have published the images and silently dropped the videos, and an older queue that was still in front of the new items would have sent one topic out twice.

So for a few days I published by hand while the publisher caught up. On one of those days a post went out with an image from one day’s version and a video from the previous day’s, because the two had been rendered at different times. Every one of these was mine to fix. With a freelancer, each would have been a message, a scoping question and a small invoice.

If you recognise this pattern (you are still deciding the format, the channels or the rules), do the task by hand until the steps stop moving. A useful test: write the steps down today, and again in two weeks. If the two lists match, you have a brief.

Sign 2: nobody on your side will own it

Every unattended automation needs a person who receives its alerts, notices when the result is missing and approves fixes. That person does not need to be technical. They do need to exist.

My own jobs have stopped silently more than once: a login token was refused and five publishing slots in a row came up empty while every run reported success. The fix was not cleverer code; it was an alert that reaches a person’s phone, plus a daily check of the login. The acceptance checklist tests for exactly this, but a test only helps if someone reads the alert afterwards.

If you cannot name that person, the automation will run fine until the first change outside it, and then stop without anyone noticing. Name them before you post the brief.

Sign 3: the hard part is a judgement call

Many tasks are 90% routine and 10% “then I decide”. The 10% is usually why the task exists. If the decision rule lives only in your head, the freelancer will guess, and you will find out at acceptance.

In my own overnight content job, two decisions stay with a person on purpose. The job may only build posts around resources that already exist, from a fixed list; it does not invent new ones, because making and publishing those resources is a human task. And topics that need a real photo or a logo are left out, because choosing those is a person’s call. Writing those two rules down was what made the rest safe to automate.

Before hiring, find every “then I decide” line in your process. For each one, either write the rule with two or three examples, or keep that step manual and automate around it.

Sign 4: it cannot run without you

If a source needs someone to log in at run time, the job cannot run on a schedule, whoever builds it. The three-test check in what to automate first covers this in detail. The short version: list every source, and ask whether it has an official way in (an API, an export, a shared sheet) and whether the login lasts between runs.

If a source fails that check, you can still hire someone, but you are buying “a tool I run by hand”, not “a job that runs”. Price and brief it that way, or wait until the source offers an export.

Sign 5: a built-in feature or template already does it

Before paying for a custom build, spend half an hour checking what your existing tools already do. Many apps have their own scheduled reports, notification rules and native connections to common tools. Automation platforms publish templates for common pairs, such as form to spreadsheet or new order to chat message.

If a built-in feature gets you most of the way, use it and live with the gap for a month. You may find the gap does not matter. If it does, you now know exactly what the custom part is, which makes a smaller and cheaper brief.

Sign 6: the maths does not work

Multiply how often the task runs by the minutes it takes, and add the errors you make by hand. Compare that with the quote plus a year of fixes, because connected tools change and something will need attention. The cost guide explains what moves a quote; the maintenance guide explains why the fixes are not optional.

A daily ten-minute task often passes this test. A quarterly one rarely does.

What to do instead

If this is the sign	Do this first	Revisit when
Process still changing	Do it by hand; keep a running list of the steps	The list has not changed for two weeks
No owner	Pick one person and give them the alert channel	They have agreed, in writing
Undefined judgement	Write each rule with 2–3 examples, or keep that step manual	Someone else can follow the rules without asking you
Needs your login	Look for an export or API; otherwise accept a tool you run	An official route exists
Built-in feature exists	Use it for a month	You can describe the gap in one sentence
Maths does not work	Leave it manual	Frequency or volume grows

When outsourcing is the right call anyway

Hire now, even if one sign is present, when:

• The task is stable and frequent, and only the technical part is missing. That is exactly what freelancers are for.
• Doing it by hand already causes costly mistakes, such as missed follow-ups or wrong figures sent to customers.
• You need someone to help you write the rules, and you are willing to pay for that as a separate, small first order before the build.

For the last case, a short paid discovery step, with written rules as its output, is often better value than a full build quoted on a brief that is still moving.

A checklist before you post the brief

If all six are yes, the brief almost writes itself: the fields are on the workflow automation page.

Wrap-up

Outsourcing works when you buy a build for a process that already exists. It struggles when you are also paying someone to discover the process for you, one change order at a time. Wait until the steps stop moving, name an owner, write the judgement down, and then hire. The build will be smaller, the quote clearer and the handover calmer.