Automations that fail loudly, not silently.
Most broken automations are not broken. They are quietly skipping records and nobody knows. I build n8n workflows the way you would build a production system, with retries, idempotency, alerting, and an audit trail, because an automation you cannot trust is worse than doing it by hand.
Who this is for
Agencies moving data between a CRM, a project tool, and a billing system. SaaS teams stitching onboarding together across four APIs. Operators who have outgrown Zapier task limits and want something they can actually reason about.
The common signal is a person whose job is partly to babysit a workflow. Somebody checks a sheet every morning to confirm yesterday ran. That person is the bug.
What I build
Systems that talk to each other
GoHighLevel, ClickUp, Airtable, Shopify, Mailchimp, Stripe, Slack, Google Workspace, and anything with a REST API. OAuth2, JWT, and HMAC signed webhooks included.
Tag driven project templating
A tag applied in ClickUp fires a webhook, looks up the right template, and creates the full task tree with computed dates, assigned owners, and SLA timers. Built this at agency scale and it removes an entire coordination role.
AI steps with a human in the loop
OpenAI drafts, summaries, and classification, always with an approval gate before anything client facing goes out. Every generated item is logged with the prompt and the approver.
Clean data moving between systems
JSON transforms, deduplication, CSV ingestion, and mapping between systems that disagree about what a contact is. Pagination and rate limits handled properly instead of hoped past.
Scheduled reports that assemble themselves
Pull from GA4, the CRM, and the project tool on a cron, assemble the numbers, and put a finished report in front of the person who needs it. No one exports anything.
The layer most builds skip
Retries with backoff, idempotency keys, dead letter handling, error workflows, and alerts to Slack or email. This is the difference between a demo and a system.
The reliability layer
Anyone can drag nodes onto a canvas and make a happy path work. What separates a workflow that survives a year is the boring part underneath it. Every build I ship includes these five things by default, and I do not charge them as an extra because a workflow without them is not finished.
Idempotency
Webhook providers retry. GoHighLevel retries, Stripe retries, almost everything retries. Without a dedupe key on the incoming event you create the same task or the same contact twice and nobody notices until a client does.
Retries with backoff
APIs rate limit and time out. A workflow that gives up on the first 429 loses records permanently. Retry with increasing delay, and cap it so a genuinely dead endpoint does not spin forever.
Dead letter handling
When something exhausts its retries the payload goes somewhere durable, a table or a sheet, with the error attached. You can replay it later. Nothing evaporates.
Error workflows and alerts
n8n error workflows catch what the main path missed and push a real message to Slack or email with the execution link. Someone finds out within minutes rather than at the next monthly review.
An audit trail
Every meaningful action gets logged immutably with a timestamp and the actor. When a client asks why their contact got two emails on Tuesday, you can answer in a minute instead of an afternoon.
How I scope a workflow
Before I build anything I want four answers, and getting them usually changes the design.
- What is the trigger, really? Not when a deal closes, but which exact event in which exact system, and can it fire twice.
- What is the volume at peak? Ten records a day and ten thousand a day are different systems. Batching decisions come from this number.
- What happens if this step fails? For each external call. Retry, skip, or stop and alert. The answer is different per step and it is a business decision, not a technical one.
- Who fixes it and how do they know? If the answer is nobody, we design the alerting before we design the workflow.
Working alongside GoHighLevel
A lot of my n8n work sits next to a GoHighLevel account, because the two cover each other's weak spots. GoHighLevel owns the contact record and the messaging. n8n owns anything that talks to the outside world or needs to survive a failure.
If that is your setup, start with how to connect GoHighLevel to n8n, which covers the three connection methods and what breaks once real volume hits. If your GoHighLevel account itself needs work first, that is the GoHighLevel side of what I do.
Questions people ask before hiring
Do you host n8n or do I?
Either. n8n Cloud is fine for most teams and removes a maintenance job you do not want. Self hosting makes sense when you have data residency requirements, heavy execution volume, or you want community nodes that cloud does not allow. I will tell you which one your situation actually needs rather than defaulting to the one that bills more.
Why n8n instead of Zapier or Make?
Cost at volume, real code when you need it, and the ability to self host. Zapier is excellent for simple linear automations and I still use it when a client already lives there. Once a workflow needs loops, batching, custom auth, or proper error handling, n8n stops being the harder choice and starts being the cheaper one.
Can you take over workflows someone else built?
Yes, and I usually find the same things. No error handling, credentials hardcoded in a Function node, and a workflow that silently stops when one API returns a 429. I document what is there, add the reliability layer, and only rebuild the parts that genuinely need it.
What happens when a workflow breaks at 2am?
You get an alert and the failed item goes somewhere you can find it. Every workflow I ship has an error path, retries with backoff, and a dead letter destination. Silent failure is the thing that makes people distrust automation, so I treat it as a defect rather than an edge case.
Will I be able to maintain this after you leave?
That is the goal. Workflows get named consistently, credentials live in n8n credentials rather than in code, every branch is annotated with why it exists, and you get a walkthrough per workflow. I would rather build something your team can edit than something that needs me forever.
Do you write code in the workflows?
When it earns its place. JavaScript in Code nodes for transforms, mapping, and validation. I avoid clever code that only I can read, because the person maintaining it in a year is usually not me.
Bring me the workflow that keeps breaking
Thirty minutes. Show me what you have, and I will tell you whether it needs a rebuild or just the reliability layer it never got. Most of the time it is the second one.
Based in Carmona, Cavite, Philippines. Working with clients worldwide, with overlap on US hours.