Three years running one business's automations: what keeps them working

The engagement, in one paragraph

Habfract Ltd. runs its sales, fulfillment, administration and reporting across Notion, Gmail, Google Calendar, Google Sheets, Shopify, Trello and Salesforce. Before automation, every handoff between those tools meant the same information copied by hand again. Since April 2023 I've built and maintained the workflows that move that information automatically, on n8n, Make and Zapier, picking whichever fits each workflow. They are still running in production today, which is the only result that matters for this kind of work.

That length of time is the point of this article. A workflow that works on launch day is easy to demonstrate. One that still works three years later has survived tool updates, changed fields, new team members and new business processes, and the habits that got it there are worth writing down.

The tool is chosen per workflow, not per business

Habfract runs all three platforms because each one genuinely fits a different kind of workflow: n8n for the ones that need real branching logic or a custom code step, Make for linear scenarios that a non-technical person should be able to read at a glance, and Zapier for simple, high reliability, single purpose zaps. Forcing one tool to do everything would have made the awkward workflows fragile and the simple ones overbuilt.

I've written about how that decision gets made in n8n vs Make. The short version is that the deciding question is who maintains the workflow afterward and how complex the logic really is, not which platform I'd rather use.

A workflow that fails silently is worse than no workflow

Every workflow in this engagement logs its failures and triggers a notification instead of quietly dropping the run. That sounds obvious, and it is the part most often skipped when an automation is built quickly. Without it, the failure mode isn't an error message. It's a report that has been silently wrong for a week, or records that stopped syncing and nobody noticed until a customer did.

The difference between catching a problem in minutes and finding out a week later is almost never the sophistication of the workflow. It's whether anyone built the boring part.

Test against real data, and assume the upstream will change

Every workflow here was tested against real data before going live, not against a tidy sample. Real data is where the exceptions live: the record with a missing field, the date in an unexpected format, the item someone renamed. The working assumption from then on is that a field will change upstream at some point, because over a long enough engagement it will.

That's why conditional routing sends each piece of information to the right system based on its type and status, and why data is transformed to match what each destination tool expects before it arrives. A change on one side is contained at the boundary instead of breaking everything downstream.

Document and hand over, even when you're not going anywhere

Each workflow is documented and handed over so the team can operate it without me, even though the engagement is ongoing. That isn't about planning an exit. It's that routine changes shouldn't need developer involvement, and a business shouldn't depend on one person's memory of how a system works. The same standard applies to a one off build: the handover is part of the work, not an extra.

Where AI fits, and where it doesn't

AI assisted logic is used wherever a workflow needs to interpret or route content rather than just move it, and nowhere else. Most of the work in a business operations stack is deterministic: this record goes there, in this format, when this happens. Adding a model to that step is a liability, not a feature. Where a step genuinely has to read something and decide, an AI step with a clear fallback earns its place, the same way it does in the Shopify support agent.