We've all written this code. You want to email a user when they sign up on y our app and then 24 hours after signup if they haven't created a project.
This starts small, until your requirements change and you add more things to this drip campaign, and you end up with logic, which we call "Spaghetti Code"
Spaghetti code is a derogatory term for disorganised, tangled source code that's hard to read, understand, and maintain, resembling messy spaghetti noodles with intertwined logic, often using excessive goto / if-else statements or procedural styles in code.
I working @ Spur also dealt with the same problem, but at a larger scale.
- User onboarding
- Subscription Creation
- Payment Failure
- Subscription Cancellation
and the list keeps on going.
All of these events require some sort of intimation or communication to happen with the customer.
Since we at spur are still scaling , we started hardcoding all our flows in code, which became a huge pain in my a** to manage , because it meant to create jobs to manage long stateful flows to manage our drip campaigns or create a lot of cron jobs. Both of which had to be debugged by searching the application logs , whenever we wanted to figure something out.
Other issue was that , to change the smallest thing , like the delay between the signup and the signup email, engineering team had to be looped in and a code push was required to make the change live.
The Solution
I moved decoupled all of this logic out of code, to an orchestration service which i made, (Flowripple). By doing so, all i need to do from my code is, fire an event using Flowripple's SDK , which sends all the data to flowripple, and then i (or more so, our Success Team) can create all the conditional and delay logic in the visual Workflow Builder.
I deleted about 400 lines of boilerplate code, but the real win wasn't the deleted code-it was the separation of concerns. The backend now handles all the business logic that it needs to do, and the workflows handle the Onboarding, Retention, Drip campaigns.
And it does all of this with the best observability and retry mechanisms, without looking at any application logs or writing a single line of code.
I built Flowripple because I was tired of wrestling with spaghetti code every time marketing wanted to change an email subject line or a given delay in the flow somewhere. If you’re facing similar headaches with your onboarding logic, feel free to grab the tool we built. It solved our problem; hopefully, it solves yours too, at Flowripple
Top comments (0)