About this case: At the client’s request, company name and specific details have been anonymized. The company operates in a competitive market where their operational efficiency is a strategic advantage.
”I had built it myself, and it worked”
The operations manager of this B2B scale-up in the mobility market was under pressure. The company was growing fast—too fast for the manual processes they had.
“We were getting dozens of new leads per day through the website. Each lead had to be enriched with company data, qualified based on criteria, and assigned to the right sales rep. That was hours of work per day, every day.”
She had no development background, but she did have a Make.com account and YouTube. “I thought: this must be automatable. And it was.”
In three weekends she built a flow that did everything:
- New HubSpot lead triggers the flow
- Company data is retrieved from the chamber of commerce API
- Lead is scored based on company size and industry
- Score determines priority and assignment
- Sales rep gets a Slack notification with all context
“The first time it worked, I felt like a hero. My colleagues were impressed. Our management said: ‘This is exactly what we needed.’”
Until it didn’t work
The problems started subtly. A lead that didn’t come through. A duplicate entry in HubSpot. A sales rep who didn’t get a notification.
“At first I thought: incidents. I fixed them manually and moved on. But they became more frequent.”
She started keeping a spreadsheet of what went wrong:
- Chamber of commerce API timeout: flow crashes, lead disappears
- Special characters in company name: JSON parse error, flow crashes
- HubSpot rate limit: too many requests, all leads from that hour are missed
- Double webhook trigger: same lead processed twice
- Empty fields: flow crashes if a field doesn’t exist
“I was spending more time fixing the automation than I ever spent on manual work. And worst of all: I never knew if something had gone wrong until someone complained.”
“My automation worked 80% of the time perfectly. But that other 20% was a nightmare.”
The dilemma: throw away or muddle through?
She faced a choice. Back to manual? Unacceptable—the company was growing too fast. Muddle through with the current flow? Unsustainable. Hire a developer to rebuild it completely? Too expensive and too slow.
“I felt stuck. I had built something that almost worked, but not quite. And I had no idea how to fix that last 20%.”
Analyze, don’t judge
Our first step: understand the Make flow. Not to judge, but to learn.
“I expected you to say: this is amateur work, we’re starting over. But you said something different. You said: this is cleverly built, just not robust.”
What she had done well:
- The logic was clear and well documented
- The steps were logically divided
- The integrations were correctly configured
- The happy path worked perfectly
What was missing:
- Error handling: if something fails, the whole flow crashes
- Retry logic: temporary errors aren’t automatically retried
- Logging: no visibility into what’s happening
- Alerts: nobody knows when something goes wrong
- Idempotency: the same input can create multiple outputs
“You drew it out on a whiteboard: here are the places where it can go wrong. There were more than I thought.”
Not rebuilding, but professionalizing
We chose a hybrid approach: the Make flow stayed the foundation, but we added a “safety net”.
Step 1: Central logging Every step in the flow now logs to a central database. If something goes wrong, we can see exactly where and why.
Step 2: Error handling per step If the chamber of commerce API fails, the flow doesn’t crash. Instead, the lead is marked as “to be enriched manually” and the rest of the flow continues.
Step 3: Retry with backoff Temporary errors (rate limits, timeouts) are automatically retried with exponential backoff. Three attempts over 5 minutes before it’s marked as a real error.
Step 4: Deduplication A check at the start of the flow: has this lead already been processed? If so, stop. This prevents duplicate entries on webhook retries.
Step 5: Alerting Slack notifications on errors, with context about what went wrong. She now knows within minutes if something isn’t right.
Step 6: Graceful degradation For edge cases that no automation can handle (complex company structures, foreign leads) there’s a manual queue. The flow recognizes these cases and routes them automatically.
“It didn’t feel like starting over. It felt like making what I had already built grow up.”
The technical details
For those who want to know—this is what we technically changed:
- n8n as orchestrator instead of Make (more control over error handling)
- Python microservice for complex logic that was too fragile in no-code
- PostgreSQL for logging and state management
- AWS Lambda for the retry queue
- Webhook signature validation to prevent external parties from triggering the flow
The migration from Make to n8n took two days. The rest of the time went to building the robustness layer.
Months later: silence is golden
The best proof that it works: she doesn’t think about the automation anymore.
“Before it was every day: what’s wrong now? Now I open the dashboard once a week to check if everything is going well. And it is.”
The results:
- No manual interventions needed anymore
- Nearly all leads are automatically processed
- Edge cases to manual queue (complex situations that require human judgment)
- Fast response time from lead to sales contact
- Sales team expanded without changes to the flow
“The best moment was when we hired new salespeople. Before that would have meant a week of work to adjust all the routing. Now it was: new name in the table, done.”
“I tell everyone now: build it yourself, but then have it professionalized. You learn enormously from building it yourself. But at some point you need someone who knows how to make it reliable.”
Lessons learned
-
80% working is not good enough
With automation the happy path is easy. The value is in how you handle the other 20%: errors, exceptions, edge cases. -
Building it yourself has value
She understood her process better than anyone, precisely because she had automated it herself. That knowledge was indispensable for the professionalization. -
Error handling is not an afterthought
In production systems error handling is 50% of the code. With no-code tools this is often forgotten—until it goes wrong. -
Logging is your best friend
You can’t fix what you can’t see. Every automation should log what’s happening, even when it’s going well. -
Graceful degradation > perfect automation
Some things you can’t automate. A system that knows its own limits and gracefully falls back to manual is better than one that crashes. -
Alerts must be actionable
”Something went wrong” is not a good alert. “Lead X could not be enriched because the chamber of commerce API gave a 429, lead is in manual queue” is.
