LANEFRAME · N8N
n8n build detail
3 of 3 builds complete
Runs on a server I control, for a flat monthly fee no matter how complex the job gets.
Same price, however complex
Each run costs the same whether it takes 4 steps or 37. I checked this in n8n’s own run history.
Gets cheaper the more you use it
The real cost is a fixed $5.35-a-month server, so the cost per run drops as volume grows. Tools that charge per step work the other way.
You own it
It runs on a server we control, so there are no outside usage limits or plan tiers to work around.
N1
Lead Sorter & Demo Booker
Takes leads from five sources, cleans and scores them, and routes each one to the right next step in under a minute.
WHAT I THREW AT IT
Caught a text message that said “sent” but never arrived
The text-message service reported success on a message that never reached the phone. The build double-checks delivery, so it caught the problem instead of trusting the “sent” label.
Every lead is logged, whatever happens to it
Whether a lead is passed on, stopped by a safety check, or flagged as a duplicate, it’s recorded in one master log, so you can always see what happened to it.
+ Show technical detail− Hide technical detailfor builders and technical reviewers
Leads come in from five different intake sources in five different shapes. This workflow normalizes all of them into one format, screens out anything malformed before it can cause downstream problems, checks for duplicate or dormant leads, enriches company data, scores fit, and then routes each lead one of four ways — straight to the founder, to a sales rep with automatic round-robin assignment, into a self-serve email sequence, or into a re-engagement flow for leads that have gone cold. High-value leads also get a real text message, not just an email.
Caught a text message that said “sent” but never arrived
The workflow doesn't just trust that the text-message API returned success — it reads back and confirms the carrier actually delivered it. That check caught a real failure mode where the gateway reported "sent" on a message that never reached the phone.
Every lead is logged, whatever happens to it
Success, guard-halt, or duplicate — every outcome writes to a master log, so nothing about how a lead was handled is ever a mystery after the fact.
N2
Failed-Payment Recovery
Automatically retries failed subscription payments and reminds the customer, so a business doesn’t quietly lose paying customers to an expired card.
WHAT I THREW AT IT
Found and fixed a check that could never work
The step meant to notice when a customer’s payment had recovered could never actually fire. I fixed it, and that revealed a second hidden bug, which I also fixed and re-checked live.
A broken connection looked exactly like a lost customer
When the payment connection was cut, the alert looked identical to a customer cancelling. Whoever watches the system couldn’t tell “our setup broke” from “we lost a customer”. You only find a blind spot like that by breaking things on purpose.
Worth knowing: Both problems were found by deliberately breaking things that already worked. They’re fixed and re-checked on real runs.
+ Show technical detail− Hide technical detailfor builders and technical reviewers
When a subscription payment fails, this workflow doesn't just flag it and stop — it runs the account through a dunning sequence: retry attempts, customer notifications, and escalation if the payment still hasn't recovered. The goal is to save the subscription automatically wherever possible, and only surface it to a human when it genuinely needs one.
Found and fixed a check that could never work
A recovery-check condition was written in a way that could never evaluate true — meaning it would have silently failed to detect when a customer's payment actually recovered. Fixed and re-verified live; fixing it also exposed a second, unrelated bug (a database column reference that didn't exist), which was fixed and confirmed the same way.
A broken connection looked exactly like a lost customer
Deliberately revoking the payment provider's API key produced the exact same operator-facing alert as a customer's subscription genuinely lapsing. Without extra work, whoever is monitoring this system can't tell "our integration broke" from "we lost a customer" — a real blind spot that only surfaces when you actually test failure modes instead of just the happy path.
Methodology note: Both findings above were caught because we deliberately broke things that were already working. That's the point of testing this way — the bugs were real, and they're fixed and re-verified against live execution logs, not just reasoned about on paper.
N3
AI Help-Desk Assistant
An AI support agent that answers from real documentation and is built to say "I don't know, let me get you a person" rather than guess.
WHAT I THREW AT IT
Replies in 4.8 seconds
Timed on a real question from start to finished reply, and confirmed on a second run. Not an estimate.
Fails safely when something breaks
I cut its access to the help docs, then asked it a real question. It didn’t crash or guess. It told the customer what happened, opened a support ticket and alerted the team.
Two off-topic questions still got an answer
It handled every question it was built for correctly, but 2 of the 60 off-topic test questions still got an answer.
+ Show technical detail− Hide technical detailfor builders and technical reviewers
Customers ask questions in plain language; the agent retrieves the relevant documentation, and answers only when it's confident the documentation actually supports the answer. When it isn't confident, it refuses cleanly, opens a support ticket, and alerts the team — rather than making something up. It was calibrated against a 60-question set built specifically to include near-miss questions designed to tempt a wrong answer.
Replies in 4.8 seconds
Not an estimate — timed directly from a real webhook call to final reply, and re-confirmed on a second run.
Fails safely when something breaks
We deliberately broke the database credential the agent uses to retrieve documentation, then sent it a real question. It didn't crash, and it didn't guess — it refused cleanly, filed a support ticket, and alerted the team, exactly as designed.
Two off-topic questions still got an answer
Out of 60 test questions, 2 genuine false-positive risks were found and are disclosed plainly rather than smoothed over — the agent correctly refuses every in-scope question, but a small number of out-of-scope questions still slip through to an answer.
Want your next automation tested like this before your customers touch it?
Fix My BottleneckSEE THE SAME JOB BUILT ON ANOTHER TOOL