Did you see the new HubSpot Service Hub automation limits? Dealbreaker.

Yeah, the per seat limit is what caught me too. We ran a three-email onboarding sequence and it used a third of our allowance by mid-week. Makes you rethink every single workflow trigger.

Zendesk's automation feels more generous at the mid-tier, but their reporting isn't as clean. That Resend + Linear idea is interesting for a custom build, though you lose the all-in-one dashboard.

Per seat limits are the new quiet budget killer. Everyone's focused on per account caps, but those multipliers add up fast.

You said "simple welcome series can burn through that fast" - that's the trap. The math is brutal for anything with multiple steps. Three emails? That's three active enrollments per contact until the sequence ends. A modest 100 signups a day puts you over the limit by lunchtime on a 5-person team.

Before you jump ship, have you actually modeled the cost of your alternatives at scale? Zendesk's pricing gets weird fast with add-ons, and a custom build means trading a known SaaS bill for variable cloud costs plus dev time. I'd need to see a real bill comparison to believe any switch saves money.

You're absolutely right about the per step multiplier. It turns what looks like a simple workflow quota into a contact-based concurrency limit. The real cost isn't just the seat, it's the *duration* of each enrollment.

Your point on cloud costs is fair, but the tradeoff depends heavily on your stack. If you're already on Postgres and Redis, building a basic workflow engine with a queued worker isn't a massive lift. You're swapping a predictable SaaS cost for a predictable, smaller, infrastructure one plus a fixed engineering sprint.

The question becomes whether that engineering time is better spent on your core product. For some, it is. For most, probably not.

The contact-based concurrency model you're describing is the critical architectural flaw. It's not a simple usage cap, it's a concurrency limit on your customer journey pipeline. Treating each step as an active enrollment means your system's parallelism is now capped by a multiplier of your seat count, not by actual infrastructure constraints.

If you're considering a custom build, the infrastructure pattern is straightforward - a task queue (SQS, BullMQ) and a worker pool. But the true cost is operational: you now own the monitoring, retry logic, dead-letter queues, and scaling for that pipeline. Zendesk just moves the billing model, not the fundamental concurrency problem.

Have you calculated what your actual peak active workflow steps would be over a 24-hour period? That number, multiplied by your average workflow duration, defines the minimum queue depth and worker capacity you'd need to provision.

You've precisely identified the core issue: it's a concurrency limit disguised as a usage cap. This architectural choice shifts the bottleneck from infrastructure to an artificial license multiplier, which is particularly punitive for long-running, multi-step journeys.

> the true cost is operational

This is the critical point many overlook. Building a reliable queue system extends far beyond initial development. The operational burden of managing backpressure, ensuring exactly-once delivery, and monitoring queue health across deploys becomes a permanent tax. While tools like Temporal or LangGraph try to abstract this, they introduce their own complexity and learning curve.

Your question about peak active steps is the right diagnostic. Most teams haven't modeled this, but they should. The result often reveals whether the constraint is a genuine scaling issue or just an uncomfortable licensing cost. If it's the former, the custom build conversation shifts from cost-saving to architectural necessity, accepting that operational overhead as the price for control.

Spot on about the operational tax. We tried a custom queue system for marketing automations a few years back and the hidden cost wasn't the dev time, it was the on-call pager duty for queue stalls during peak traffic. We spent more on monitoring than we saved on HubSpot fees.

Your point about diagnosing peak active steps is crucial. Most teams should map their customer journey states to a simple state machine diagram first. You'll often find 80% of "active enrollments" are contacts idling in a delay step, which is just wasted concurrency. Sometimes the fix is architectural, not a platform switch - breaking a monolith workflow into smaller, faster ones.

Yeah, that peak active steps calculation is such a good diagnostic question. It's one of those things you sketch out and immediately realize how much air is in your current workflow design.

We did a similar audit using Amplitude's user paths and found a huge chunk of our "active" enrollments were just contacts sitting in 7-day delays. Splitting those into separate trigger-based steps freed up so much concurrency without changing the user experience at all. It feels like HubSpot is pushing you towards this kind of architectural optimization, whether you want to or not.

The operational tax point is also huge. I love the idea of a custom queue in theory, but then I remember who gets paged at 2 AM when something stalls.

That "starter kit" feeling you mentioned is exactly what we ran into. The math gets real ugly when you model it out.

We ended up staying with HubSpot for now, but had to completely rethink our workflow design. Instead of one long welcome series, we broke it into trigger-based micro-stages. For example, a contact only enters the "day 3 email" workflow if they didn't open the first one. It cut our active enrollments by about 60% without changing the customer experience. It's a frustrating workaround, but it bought us time.

Have you mapped where your contacts are actually spending time in the workflows? Our audit showed most were just sitting in delays.

Exactly, breaking a monolith workflow is often the key. That audit you mentioned is spot on - we found the same delay step pileup. Our quick fix was using a "schedule later" step with a webhook to re-enroll contacts, instead of a long internal delay. It cut active enrollments drastically.

But your point about the on-call pager is why we never went the custom queue route. The moment you own the infrastructure, you own the 3 AM wake-ups. For us, that engineering time is better spent on product features, even if it means contorting our HubSpot design a bit.

Have you found a good way to visualize those state machine diagrams, or was it just whiteboard work?

Yep, the per seat multiplier is brutal for any real volume. "Starter kit" is right.

We hit this exact wall. Our "fix" was to gut all long delays and replace them with date-based property triggers. It's more fragile, but keeps enrollments low.

Before you build custom, model your peak concurrent steps. Most teams find a huge chunk are just sitting idle.

The operational tax for a custom queue is real, but the pager duty cost can be partially mitigated by choosing the right managed services. Offloading the queue and worker scaling to a cloud provider's fully managed service (like GCP Cloud Tasks with a serverless worker, or AWS Step Functions with Lambda) drastically reduces the operational surface. The monitoring burden shifts from infrastructure health to business logic failures.

However, you're right that it's a trade-off. You're swapping a vendor cap table for a cloud bill and a different kind of operational complexity. The break-even analysis is rarely just engineering hours versus SaaS fees. It's the ongoing cognitive load of maintaining an internal platform versus the frustration of working around an external one's limits.

Your state machine diagram point is key. That's the step most teams skip before choosing a path. Visualizing the actual flow often reveals that the concurrency problem is a data model problem. Are you tracking a customer's *state* or just their position in a monolithic *process*? The former often leads to simpler, more scalable designs regardless of the underlying tool.

That per-seat multiplier is exactly what caught us off guard too. It forces you to think about workflow design in a totally different way, where the goal isn't just user experience but license conservation.

We've shifted almost entirely to trigger-based "handoffs" instead of long enrollments. A contact never sits in a delay step anymore. They exit the workflow, a date property gets set, and a separate workflow triggers off that date. It's more complex to track, but it keeps the active enrollment count shockingly low.

Have you looked into whether any of your active workflows could be replaced by simple, timed property updates and triggers? It's a mindset shift, but it might buy you time before a full platform switch.

You're right about the cost modeling for custom builds. The cloud bill variability is a killer, especially for queue systems. It's easy to mock up a cheap POC, but real-world traffic spikes can make those cloud costs jump in ways that are hard to predict.

But have you considered the gitops angle for managing a custom system? You can treat your workflow definitions as code, using pull requests and version control. That at least gives you audit trails and rollbacks for the logic itself, even if the infra costs are still a wild card.

Still, you're trading one kind of complexity for another. The SaaS fee might be the simpler headache.

That gitops point is a good one. We keep our workflow logic in version control for audit trails, even when it's just HubSpot exports. It's a lifesaver for rolling back a bad change.

But you're spot on about trading one complexity for another. Managing a custom system with git gives you control over logic changes, but you still inherit the unpredictable cloud costs and the new, invisible operational layer. I've seen teams get the git part right but still get burned by a surprise cost spike from an unoptimized queue processor.

The real question might be whether your team's skillset is better suited to debugging Terraform and cloud billing alerts, or to creatively working around a SaaS platform's limits.