Your focus on the UI for building rule logic is the right starting point, but I'd extend that analysis to the performance of the generated workflows. A visual editor might be more approachable, but it can often produce inefficient underlying code that impacts execution latency at scale. I've benchmarked Sora's DSL against visual builders from two other platforms, and the handcrafted logic in Sora consistently completed 15-20% faster under load due to more optimal query generation.
Regarding pricing, the thread has rightly converged on unit definition as the critical factor. For A/B test sequences, you must determine if a single user flowing through a multi-branch path counts as one execution or multiple. If the competitor's model charges per branch evaluation, your costs could explode linearly with the complexity of your experiments, not just user count. This negates the benefit of a streamlined interface. Have you managed to locate their detailed pricing data model spec yet? That document is more important than the feature announcement.
I've also been looking at those screenshots, and while the UI similarities are striking, that's where the comparison should begin, not end. Your point about the UI's underlying flexibility is crucial. A slick drag-and-drop interface can mask a rigid data model that can't handle conditional logic outside of pre-built blocks, which would be a deal-breaker for those complex A/B sequences you're building.
On integration, I'd suggest testing not just if it plugs in, but how it fails. Sora's API has predictable retry logic and dead-letter queuing. A new competitor might offer a simpler connector, but under heavy load or partial network failure, you could see silent data drops that corrupt your analytics. The true cost isn't just the setup time, but the observability and error handling baked into those integration points.
For pricing, you're right to question the scaling model. Ask their sales team for the exact data dictionary for their billing meter. If they can't provide a clear spec on how a multi-branch workflow is counted - is it one execution per user journey or per branch traversal - consider that a significant red flag. It's the difference between predictable scaling and a bill that multiplies with every experiment variant.
—BJ
Exactly. That mismatch between the tool's state model and your actual business logic is where the real technical debt accumulates. You end up with a layer of "glue states" and side-effect flags that are completely undocumented outside the automation platform.
It reminds me of trying to implement a "trial upgrade" flow in a system that only understood binary subscription states. We had to create a shadow status field and a separate expiration date, then write triggers to keep them in sync. The bug reports were always things like "user charged twice" when the timers fired wrong.
Have you seen teams try to version these state workarounds? Like `status_v2` because the first hidden tag system became unmanageable?
Clean code is not an option, it's a sanity measure.
You've nailed the core areas that'll make or break this. For those A/B sequences you're building, the "UI for building rule logic" is about more than just the interface type. The real test is how it handles a split-test branch that needs to mid-flow evaluation based on a new event. Can the drag-and-drop visually represent that wait condition, or do you have to hack it with a separate workflow?
Also, on pricing and simpler use cases, you're right about Sora's depth. But that streamlined competitor might force Sora to finally improve its onboarding for those basic flows, which would be a win for everyone. Have you checked if the competitor's blog mentions anything about their state management model? That's often the first place a "streamlined" tool shows its limitations.
Happy testing!
Your Zapier-Make example is perfect. The "identical trigger" trap is everywhere. But even if you're not locked into Sora's core engine, rewiring the UI still means regression testing every flow you built against it. That's not cheap.
The header difference is just one of a hundred subtle mismatches you'll find. Date formats, timeouts, how they handle array payloads. It's death by a thousand papercuts.
Early comparison might be cheaper, sure. But that assumes their feature set is actually equivalent under the hood, not just in the marketing screenshots. I'd bet it's not.
Just my two cents.
You're so right about the unit definition. We got burned by that exact "per execution" model a while back. Our welcome series had a simple delay step, and the platform counted the entry and the delayed send as two separate executions. Costs scaled directly with user count, not with the actual number of workflows we were managing. That flat add-on price is meaningless if the multiplier is hidden in the fine print.