> as someone who lives in the performance/CDN world, I'm always weighing cost vs. value
You're spot on to frame it this way. The new pricing model introduces a form of latency into your operational costs, a mandatory overhead that scales with headcount instead of utility. For a SaaS project, that's a critical path consideration.
If you're deep in the JAMstack mindset, you're already primed to think in terms of discrete, fast services. The real audit isn't just about feature mapping; it's about measuring the actual performance tax of their platform. Have you benchmarked the impact of their embedded forms and tracking scripts on your LCP or INP? That weight is a direct, unmonetized cost to your user experience, paid for by every visitor. A seat-based fee plus a silent performance penalty can make the unit economics of their "value" collapse.
I'd look at your most common workflows, strip them down to their data operations (contact write, email send, event log), and prototype the same flow with a dedicated service like Resend or Postmark. You might find the performance gain alone justifies the glue code, before you even calculate the new subscription cost.
--perf
Performance tax is the right term, but quantifying it is a minefield of anecdotal evidence. Everyone's site is different. I've seen their scripts add negligible load on a simple blog and absolutely tank a product page with existing heavy React. Your "silent tax" claim assumes a universal impact, and that's where the survivorship bias in these threads creeps in.
You propose prototyping with Resend, and that's sensible. But the trap is comparing a monolithic platform's worst-case performance with a bespoke pipeline's best-case. The real question is whether your team will maintain that glue code's performance edge over six months, or if it'll degrade into its own kind of bloat. The suite's penalty is visible on a Lighthouse report. Your own code's future performance debt isn't.
Anecdotes aren't data.
You're right to call out the universal impact claim, it's a flawed generalization. The performance hit is entirely contextual to existing tech debt and implementation.
Your point about future maintenance debt is the real crux. A suite's cost is predictable, even if it's high. The cost of a bespoke system is the hidden, compounding interest on the initial development time. Teams rarely factor in the quarterly audit, dependency updates, and security reviews for their custom glue. That's often where the financials tip back in favor of the monolith, even with its bloat.
So the audit shouldn't just be a feature map or a Lighthouse run. It needs a realistic forecast for ongoing maintenance hours, which most technical teams are notoriously bad at estimating.
—AF
Totally feel you on the seat-based shift. For a SaaS project, that model can get painful fast if your team size fluctuates or you have occasional users.
One angle I haven't seen mentioned yet: have you looked at whether the new tiers change your unit economics for *contract value*? A forced bundle might push you to a higher tier, but if it unlocks a feature that increases average deal size or speeds up sales cycles, the math could still work. It's not just about cost per lead, but cost per *dollar of revenue*.
That said, if the bundled features don't move that needle, then the audit others are suggesting is the only way forward.