I'm the founding engineer at Spur, and I think we've all written the same bad code. You want to email a user when they sign up, and then check 24 hours later if they created a project. It starts simple, but eventually, you end up with a mess of cron jobs and spaghetti logic.
The breaking point for me wasn't the code complexity, but the process. Every time our marketing team wanted to change an email subject or bump a delay from 1 day to 2 days, I had to stop what I was doing, write code, and push a deployment. It felt ridiculous to deploy a new build just to change a timer.
I ended up ripping about 400 lines of boilerplate state-management code out of our backend. I moved all that logic to an orchestration layer instead (I built a tool called Flowripple for this). Now my backend just fires a 'user_signed_up' event and forgets about it. The orchestration layer handles the state, the delays, and the retries by a visual workflow builder on flowripple.
It has mostly solved the "separation of concerns" headache for us, but I'm curious how you all handle complex onboarding flows? Do you stick with Cron/Queues to keep it simple, or do you offload the state management elsewhere?
For now it's using my email server, but i am open to add a smtp email integration to send it via user's service , i was conflicted which one should i integrate and just solved my problem for now and thought of thinking at scale later when i actually make it public .