Product Thumbnail

Flowripple

Easily Trigger workflows from your SaaS

Productivity
SaaS
No-Code

Hunted byShiv SarthakShiv Sarthak

Automate your SaaS workflows with minimal code. Visual workflow builder that lets your whole team manage triggers, integrations, and automations without code deploys.

Top comment

At my startup, we were hardcoding every lifecycle event such as user onboarding sequences, subscription renewals/cancellations, payment failure retries etc. The technical debt was piling up, we had to create complex background jobs to manage long-running delays (e.g., "Wait 3 days, then check X"). If a user didn't get an email, we were digging through massive application logs to find out where the logic branched off or if every time marketing wanted to change a delay from 24 to 48 hours, or edit a subject line, it required a PR and a full code deployment. The Solution: Decoupling via Event-Driven Orchestration which I ended up naming Flowripple I realized these flows shouldn't live in the core business logic. I moved the logic out of the app and into an orchestration service. Deleted 400+ lines of boilerplate and Separation of Concerns: The backend handles the database; the visual workflow builder handles the "if/then/wait" logic. Non-Eng Autonomy: The success team can now adjust delays or email copy in a UI without asking for a code push. Retries & Observability: We get a visual trace of every user's path through the flow, which makes debugging instant. I ended up building this into a tool called Flowripple because I couldn't find a lightweight way to do this without the overhead of massive enterprise tools.

Comment highlights

The webhook trigger approach is clever - curious how you're handling the credential storage side when customers connect their SaaS tools. Are you storing OAuth tokens per-tenant or doing something like short-lived token exchange? That pattern gets messy fast when you start adding more integrations.

Shiv, this is really cool. The problem you’re solving is one I see kill momentum at so many SaaS companies: marketing wants to move fast, engineering is stretched thin, and lifecycle workflows become this awkward no man’s land where nothing gets done quickly.

The visual builder plus full observability is a smart combo. Non technical folks get real autonomy, and there’s no messy technical debt piling up in the background.

One thought on messaging: “time to iterate” could be a sharper hook than just listing technical benefits. PMs and growth leads care about speed and not being blocked, so if that angle comes through faster, the value probably lands even harder. As someone who helps SaaS teams sharpen messaging, I’d love to see how you’re framing this to prospects; it feels like there’s a strong story that could really resonate.

Curious, what are your early users actually building first? Onboarding sequences seem like the obvious starting point, but I wonder if some teams are using it for flows you didn’t expect.

Rooting for this one. Flowripple could really change how teams think about owning their workflows.

This is actually great solution - I plan on trying this soon with my team soon. Quick question on the visual trace feature: if a user hits a multi-split branch, can you filter the logs to just see the users who went down path B?

rooting for you today.

This resonates hard. I've dealt with the exact same pain -- hardcoding onboarding sequences and payment retry logic that should never live in the core app. The 400 lines of boilerplate you deleted is such a relatable number. The visual trace for debugging user paths is a killer feature too. When something breaks in a background job at 2am, having a clear visual of where the flow diverged saves hours. How does integration work on the SaaS side -- is it a webhook-based trigger system, or do you provide an SDK that fires events directly?

The non-eng autonomy angle is what stands out here. Every SaaS team I have seen has this exact pain where marketing or success wants to tweak a delay or change an email subject line and it turns into a full engineering ticket. Making that a visual workflow change instead of a PR is a huge unlock. Curious how you handle versioning when a flow gets updated mid execution. Does a user who started on v1 finish on v1, or get switched to v2?