The network for creativity
Join 1.25M professional creatives like you
Connect with clients, get discovered, and run your business 100% commission-free
Creatives on Contra have earned over $150M and we are just getting started
Back to feedPost
Here's a duplicate-record bug that arrives without an error and is nearly impossible to reproduce on demand.
You build a webhook handler that creates a deal in your CRM when a payment event fires. Testing is clean. In production, occasionally the same payment creates two records — same customer, same amount, a few minutes apart.
The cause: your payment processor retries on network timeout. If your handler takes a few seconds to respond (say it's chaining three downstream API calls), the processor assumes something went wrong and fires the same event again. Both runs succeed. Nothing in your logs looks wrong because nothing did go wrong — the handler worked exactly as written, twice.
The fix is two parts. Every incoming webhook event has an ID. Before writing anything, check whether you've already processed that ID — a key in your database or cache is enough. If it exists, return 200 and stop. If it doesn't, write it first, then proceed. That way a retry on the same event hits the check and exits cleanly.
The rule underneath it: a 200 acknowledges receipt, not uniqueness. Any webhook handler that creates or modifies state needs to treat duplicates as a given. The event ID is how you enforce idempotency.
The network for creativity
Join 1.25M professional creatives like you
Connect with clients, get discovered, and run your business 100% commission-free
Creatives on Contra have earned over $150M and we are just getting started
Challenges
View all
Related posts
The trips ran daily. The invoicing ran monthly. Nobody calls that a problem, it is just how billing works.
At The Joshua Agency it took 30+ days to get from a completed trip to a cleared invoice. They run wheelchair, stretcher and sedan trips as a non-emergency medical transport operator across Alabama and five more states, so there is a lot of finished work sitting in that queue at any moment.
Six Make.com scenarios later, it takes 7.
What runs, every cycle:
Capture. Every completed trip as it closes. Nobody re-keys anything.
Check. Rates and trip detail before anything goes out. A wrong line item is not a small delay, it is a whole cycle lost.
Build. The invoice packet with the full breakdown attached.
Send. To the right payer, then track it until it clears.
Same trips, same team, same drivers. The waiting is what left.
Two things I would do the same way again:
Fix the checking step before the sending step. Everyone assumes the delay is getting invoices out the door. It usually is not. It is the back and forth afterwards, and that is caused by what was wrong when it went. Validate before you send and most of the chasing disappears on its own.
Measure the cycle, not the tasks. "Invoicing takes us two days" is the wrong number. The one that matters is days from finished work to cleared invoice, because that is the one the business actually feels. Most operators have never measured it, which is why it never gets fixed.
Figures in the image are illustrative and there is no passenger data on it, for obvious reasons.
If you run trips, jobs or site visits: do you know your number? Days from finished work to cleared invoice. Reply with it and I will tell you which step is eating it.
NovaMart — AI-Powered E-Commerce Automation Suite
Four connected AI workflows that turn every customer action — order, support ticket, abandoned cart, low stock — into an automated response.
Everything after checkout is still done by hand for most stores — and it doesn't scale. Abandoned carts go unrecovered with no follow-up, support tickets are read and routed manually, order confirmations are pushed out by a person, and stock-outs are only discovered after they've already cost sales.
I built NovaMart, a Next.js 16 storefront backed by four orchestrated n8n workflows that automate the entire post-checkout lifecycle. The moment a customer places an order, abandons a cart, or files a support request, the system takes over: orders move through confirm → ship → deliver → review automatically with every step visible in Slack; GPT-4o-mini classifies incoming support requests and routes them without a human in the loop; idle carts trigger timed recovery emails with a discount nudge; and daily inventory checks flag low stock and auto-pause zero-stock items before they turn into lost sales.
A single Supabase database acts as the one source of truth across the entire system, so there's no fragmented data between the storefront, automation layer, and support tools.
Results: Zero manual triage in the support loop, recovered revenue from carts that would otherwise have been lost, one unified source of truth instead of scattered spreadsheets, and inventory management that's proactive instead of reactive.
Stack: Next.js 16 (storefront) · Supabase (database, auth, real-time) · n8n (4 orchestrated workflows) · GPT-4o-mini (support classification) · Slack (team alerts) · Gmail API (customer communications).
If your store still runs on manual order tracking, ad-hoc support replies, or spreadsheet inventory checks, this same 4-workflow system can be adapted to your storefront in days.
New marketing site for a CRM platform
The easy trap with a SaaS homepage is listing every feature and hoping something lands. What actually moves people to book a demo is picking the few that matter most and stringing them into one story, not a feature dump.
Right now, that story centers on three things: surfacing overdue follow ups before anyone has to ask, keeping the full client relationship visible on one screen, and automations that handle renewal flags and follow ups in the background. Each one earning its place before the next gets added.
