Alderson Labs

The challenge

The AI market is full of “we’ll automate everything” promises. The problem with that pitch is that it moves all the risk onto the client: they pay for the deployment before anyone has calculated whether the task is worth automating at all.

Alderson Labs - an agency that works project-based itself - sat through several of those conversations. Every team started from technology: which model, which platform, which integrations. None of them started with the only question that matters to an agency: which of our repetitive tasks are actually worth automating, and which aren’t?

In an agency, the cost of getting that wrong is double. You pay for the deployment, then you pay again - in the time of a team that now has to operate a tool generating more work than it saves.

What we built

We reversed the typical AI deployment order - the maths first, the code second:

1. Process mapping - workshops with the team: what repeats, how long it actually takes, who does it and how often. Without this, every number that follows is guesswork
2. Per-process maths - for each task we set today’s cost (time × rate × frequency) against the cost of building and maintaining the automation, which gave a realistic payback period
3. Selection, including saying no - only processes with a clear return made it into the scope. For the rest we said plainly that automation wouldn’t pay off - even though each was technically feasible and perfectly sellable
4. Iterative rollout - automations launched one at a time, each measurable from week one, so the audit’s assumptions could be checked against data rather than declarations

Why we argued part of the scope away

This is the most commonly skipped part of AI projects. Automating a process that runs twice a month and takes fifteen minutes will never pay for itself - the cost of maintaining the integration outweighs the saving. Selling that deployment is easy, because the client has no way to verify it before paying.

Identifying those processes and cutting them from the scope lowered our own invoice. We took it as the cheapest possible way to build a relationship where the client also believes us about what we recommend.

Why we built our own MCP servers

Automations in n8n are assembled from ready-made nodes, and as long as a process touches popular tools that is the cheapest route. The trouble starts where a system has no node at all, or one covering a fraction of what’s needed. The classic workaround is a raw HTTP request node: it works, but every change on the API side comes back as a support ticket, and the model gets a call it cannot reason about.

Instead we wrapped those integrations in our own MCP servers. To the model it isn’t a raw endpoint but a named set of operations with described parameters - it knows what it may do and what it may not. To us it’s a single layer maintained in one place, rather than the same fix applied to every workflow separately.

The cost: a few extra days up front. The gain: automations that don’t fall over the first time something changes on the other side of an integration - and that maintenance cost is exactly what decided, back in the audit, which processes were worth automating at all.

Results

We delivered exactly what the audit called for - no scope creep, no automating for automation’s sake. Alderson Labs now has not just working automations, but a document explaining why these processes were automated and not others - one that stays valid for the next round of decisions.

What this means for you

Before you ask a vendor “what can you automate”, ask “what would you advise against, and why”. A team without an answer to that probably hasn’t calculated the payback - which means the deployment risk sits entirely with you.