Automate the work nobody wants to do
Most automation stops at moving data between two SaaS tools. We build the kind that reaches into your own database, decides what to do, and keeps running when nobody is watching.
Automation earns its keep when it runs unattended against systems you own. Connecting two public SaaS apps is a settled problem, and a per-task tool solves it in an afternoon. The work that costs you a headcount is different. It touches a private database, needs a judgement call, and has to be right on a Sunday night.
Where the hours actually go
Ask a team where its time goes and the answer is rarely one big task. It is re-typing an order into a second system. Reading a transcript to find what somebody promised. Checking whether a job was invoiced.
Each one is small. Together they are a role. They survive because the systems involved were never meant to talk, and because the person doing the work applies judgement nobody wrote down.
- 01Data re-entered by hand because two systems have no shared key.
- 02Decisions made in a meeting that never reach the tracker.
- 03Work that only moves when somebody remembers to check.
- 04A spreadsheet that has quietly become production infrastructure.
Four shapes of automation
Real systems, named. Each of these is work we have shipped or work the same pipeline carries.
Unattended pipelines
A trigger fires, the work happens, and nobody watches it. Little Tree's meeting pipeline reads a Fireflies transcript, refines it with an OpenAI call, then creates ClickUp tasks routed to the right department.
Automation that decides
Some steps need a judgement, not a rule. A model reads the input and picks a route, with the prompt, the schema and the fallback all versioned. When it is unsure, a human gets asked instead of guessed at.
Systems that do not have an API
The tool holding your data may not want to share it. We reach it the way it allows: a database read, an export on a schedule, a scraped report. That is where SaaS-to-SaaS automation gives up.
The part that runs it
Retries, alerting, execution logs, and a place to see what ran. Automation without this is a demo that has not failed yet.
- TriggerWebhook, schedule or a row that changed.
- ReadYour database, not a copy of it.
- DecideRules where rules work. A model where they do not.
- WriteInto the system of record, with an idempotency key.
- FailRetry, log, then wake a human. Never silence.
Most automation projects build the first four stations. The fifth is the one you find out about at 2am.
Deciding what happens when a step fails
The canvas is the easy half. The real design work is failure. What happens when step nine of twelve returns a 500? And does re-running the whole thing charge your customer twice?
You get those answers before anything is built. Some steps are safe to repeat. Others need an idempotency key. The rest get retried, parked for a person, or escalated to whoever is on call.
- Every write is either repeatable or keyed, so a retry cannot double it.
- A failed run raises an alert with the input attached, not a silent log line.
- Credentials live in a store, never in the workflow body.
SaaS glue against systems you own
Both are legitimate. They fail in different places, and buying the wrong one is the common mistake.
| Criterion | SaaS-to-SaaS glue | Automation on your own systems |
|---|---|---|
| What it reaches | Public apps with a published API. | Your database, internal services, and the public apps too. |
| Where it runs | The vendor's cloud. Your data goes there. | Infrastructure you control, so data residency has an answer. |
| Custom logic | A code step, sandboxed and limited. | Whatever the problem needs, in ordinary code. |
| Cost behaviour | Billed per task, so high volume gets expensive. | Billed as infrastructure, so volume is mostly free. |
| Who maintains it | Anyone on the operations team. | Anyone, if it was handed over properly. Nobody, if it was not. |
| Honest verdict | Right for a handful of low-volume connections. | Right once a failure has consequences somebody answers for. |
The stack
Orchestration
Models
Integrations we have shipped
Operations
Automation we run in production
From first call to something running
Scoping calls are free. A paid two-week diagnostic applies only where we have to go into an existing codebase first.
- 01
Trace the process
One real case, followed end to end, with every hop written down. This is where the automation candidates appear. It is also where you find the steps that should be deleted rather than automated.
- 02
Design the failure path
Before the happy path. Which writes are repeatable, which need a key, what gets retried and who gets woken up.
- 03
Build one workflow
The highest-value process first, running against real data. You see it working before the second one is scoped.
- 04
Dry run on history
We replay past inputs through the pipeline and compare against what actually happened. For Little Tree that meant running historical transcripts before anything went live.
- 05
Hand it over or hold it
Your team gets trained on the workflows and the runbook. Or we stay on under an agreed service level. Both are real options, and neither is the default.
“Their attention to detail, quality of employees, and work ethic were outstanding.”
Nicolas de Quesada · President, Lexpair
Questions buyers actually ask
01Will this break the moment one of our tools changes?
Parts of it will, and the design decides how loudly. An automation reading a documented API survives most vendor changes. One reading a scraped report does not, so that part gets isolated and alerted on rather than treated as stable. A failure you can see is cheap. The one that runs silently wrong for three weeks is not.
02Do we have to use n8n?
No. n8n is the default when a non-engineer has to read the workflow later, because the canvas stays legible to someone who did not build it. When a half-finished run is a real incident, a written service and a durable queue are the better answer. The tool follows your failure requirement, not our preference.
03Can automation touch our production database?
Yes, and that is usually the point. Self-hosted n8n runs on your infrastructure, so your data never goes to a vendor's cloud. Reads come first. Writes go through the same review any application change would get, and every write into a system of record carries an idempotency key.
04What does it cost to run?
Where it runs decides that, and the two models behave differently. Zapier bills per task, counting each successful step in a Zap. n8n Cloud bills per execution, meaning one full workflow run whatever its size. Self-hosted automation is billed as infrastructure instead: a container, a database, and someone who owns upgrades. High-frequency work is where the gap stops being academic.
05How much of this should be AI?
Less than most vendors suggest. A model belongs where the input is unstructured or the rule is genuinely fuzzy, such as reading a transcript for commitments. Everywhere else a plain rule is cheaper, faster and testable. Little Tree's pipeline uses both, and the boundary between them is written down.
06Who owns it afterwards?
You do. Workflows export as JSON, the code inside them is ordinary JavaScript or Python, and your credentials stay in your own store. Your team gets trained on it, or we stay on under an agreed service level. What you never get is a system only its author can maintain.
Go deeper
- our n8n review →The verdict on the tool we build most of this on, from running it.
- n8n alternatives →Temporal, Windmill, Make and Zapier, and when to stay put.
- n8n automation agencies →How to tell a specialist from a reseller.
- n8n vs Zapier →Per-task pricing and 9,000 apps against self-hosting and a code node.
- taking a prototype into production →What has to be true before an AI workflow runs unattended.
