The Brief
Customers were paying. Some of them then received the onboarding email sequence twice; others never received it at all. The business could see the symptom in support tickets but nobody could say which part of the Stripe to MailerLite chain was producing it. They did not want a rebuild. They wanted to know what was wrong, in writing, before anyone changed anything.
What I Built
- Milestone one, a two-day audit as its own deliverable. I traced every path from a Stripe payment event, first payment and renewal alike, through the webhook handling into MailerLite: which group a subscriber lands in, which tag is applied, which automation that tag triggers. The output was a written findings document: which paths fire twice, which never fire, and why.
- Milestone two, the fix. With the causes named, a second contract corrected the event handling so the onboarding sequence is triggered on first payment only and renewals do not re-enter it.
- A record the client keeps. The audit document doubles as the map of the integration, so the next person who touches it starts from facts rather than from support tickets.
2contracts, January 2026, both closed and reviewed
2 daysthe audit, scoped and paid as its own milestone
1written findings document before any code changed
0rebuild. The existing integration was corrected, not replaced
Why It Holds Up
Audit first is how I take on any failing integration. The client pays for a diagnosis, reads it, and only then decides whether the fix is worth funding. It keeps the second milestone small, because the fix targets the cause the audit named instead of the symptom that raised the ticket, and it means the client is never paying for an engineer to discover the system on their time.