Why we rebuilt our messaging stack for AI apps
Earlier this year, while building Nely.ai, other developers started asking to use our internal messaging API. What we had built to support our own product was solving problems they were also facing, especially around WhatsApp, pricing, and operational complexity.
At first, exposing the API seemed like the obvious next step. But very quickly, it became clear that the problem was not access. The problem was the CPaaS model itself.
AI apps changed how messaging is used
Traditional messaging platforms were designed for human-driven communication. One user sends one message at a time. Pricing, APIs, and tooling evolved around that assumption.
AI apps do not work this way.
Conversations are generated, routed, retried, and managed automatically by agents and workflows. A single user interaction can trigger multiple background messages, retries, classifications, or follow ups. Messaging becomes part of an execution graph, not a single action.
Most CPaaS stacks were not designed for this model, especially when pricing is tied to per message usage and fragmented providers.
Pricing breaks first
When AI agents are involved, per message pricing becomes unpredictable very quickly. Messages are no longer a proxy for value. Many of them are internal, transient, or part of automation logic.
What actually matters is how many users your system is actively serving and the underlying carrier costs required to deliver those messages.
This is why we moved away from raw message counting and rebuilt pricing around MAU combined with transparent carrier pass through. This model aligns much better with how AI apps scale and makes costs easier to understand and forecast.
Automation needs fast access to channels
When you automate communication with AI, you usually do not care about providers or setup steps. You just want access to the channels your users already use.
In many cases, that means WhatsApp or SMS, and that requires a phone number. Getting that number should be fast, simple, and predictable. Waiting days, dealing with external vendors, or navigating fragmented dashboards breaks development flow and slows down experimentation.
We made phone number provisioning a first class part of the platform. Developers can get an API key, provision a number, and start sending messages in minutes. Everything works together by default, so teams can focus on building AI workflows instead of wiring infrastructure.
Rebuilding the developer experience
Modern developer workflows expect clean abstractions, strong typing, and predictable behavior. Messaging APIs, especially WhatsApp, are often fragmented, inconsistent, and hard to reason about.
We rebuilt the developer experience from scratch with modern SDKs and simpler primitives. The goal was to abstract away provider specific quirks and expose a consistent interface that fits naturally into AI driven systems.
Instead of adapting AI workflows to legacy CPaaS constraints, we designed the messaging layer around how AI apps are actually built today.
What this enables
Rebuilding the stack enabled faster iteration, cleaner architectures, and messaging that no longer feels like a bottleneck. Teams can focus on agents, workflows, and product logic instead of pricing surprises and provider management.
This work became Zavu, a unified messaging API designed for AI apps and modern communication SaaS.
You can learn more at https://zavu.dev and explore the documentation at https://docs.zavu.dev.
If you are building AI driven products and have struggled with CPaaS complexity, pricing, or developer experience, we would love to hear what has broken for you.
Top comments (0)