I just recorded a CPaaSAA Talk with Greg Fawson and Zach Powell from Mobile Seasons, the team behind developer communities and events like droidcon. We’re kicking off a partnership with them, and the timing is perfect—because the conversation quickly exposed something the telco and comms industry still underestimates.
In our prep call a couple of weeks ago, one of the first things Greg said was: “Remind me—network APIs… what are those exactly?”
Greg isn’t out of touch. He’s been in tech since the early days, and Mobile Seasons has spent years deep inside real developer ecosystems. If he hears “network APIs” and needs to mentally “place it in a box,” we can safely assume a huge chunk of developers don’t instinctively understand what telcos are offering—or why they should care.
That’s the gap. And it’s fixable.
Developers Don’t Adopt Capabilities. They Adopt Relief.
Greg’s first point was the simplest—and maybe the most important.
Developers don’t get excited about “capabilities.” They get excited about removing pain.
In telco land, we often lead with what the network can do: identity, security, QoS, anti-fraud signals, location verification, number verification, SIM swap checks, and so on. All real. All valuable.
But developers tend to think in a different mental model:
- Device APIs (camera, sensors, GPS).
- Cloud APIs (storage, compute, payments).
- Communication APIs (messaging, voice, video).
“Network APIs” as a category doesn’t automatically connect to a clear problem in their head. There isn’t a natural “neurons firing” moment unless you translate it into something they recognize as urgent and concrete.
So the question isn’t “How do we push network APIs to developers?”
It’s: “What developer pain do these solve so well that adoption becomes obvious?”
Greg framed it bluntly: what can I build today that I couldn’t build yesterday—and how does it remove friction?
The CPaaS Lesson: It Took 15 Years to Make “One Line of Code” Feel Normal
Zach brought a useful reality check from his own CPaaS DevRel journey at Nexmo, later Vonage (now part of Ericsson).
We forget how messy the early days of CPaaS were. Fifteen years ago, sending a message through an API was not the smooth, global, reliable “single line of code” experience we now take for granted. It worked in some places, with some carriers, with strict rules, inconsistent behaviors, and plenty of edge cases.
It took a long time—and a lot of aggregation and harmonization—to turn that chaos into something developers could trust.
Network APIs are at the start of a similar curve.
Today they work in certain countries, with certain operators, with versioning challenges and real-world constraints. If anyone expects “instant CPaaS-level simplicity,” they’re setting the ecosystem up for disappointment.
Zach’s point was pragmatic: this is exactly where CPaaS players (and other aggregators) still have a role—because many developers, startups, and indie builders don’t want to manage operator-by-operator complexity. They want to make a single request and have someone else worry about how it reaches users around the world.
Enterprises with large developer fleets might build their own routing logic. Most of the market won’t.
The 10-Minute Window: If You Can’t Try It Fast, You’ve Lost Them
Zach also hit a truth that anyone who’s built a developer product recognizes.
A developer will decide—fast—whether something is worth their time. Often within ten minutes.
That means the “developer experience” can’t be an afterthought. If network APIs require long onboarding, unclear steps, or complicated access, you’re not just slowing adoption—you’re killing it.
His checklist wasn’t fancy, but it’s the difference between “interesting idea” and “actual usage”:
- Good documentation.
- A developer portal that makes the value clear.
- A sandbox to test quickly (even if real-world usage has regulatory hoops).
- A frictionless path to first success.
Because even when product owners are convinced at the business level, if developers hit friction, the initiative will stall internally. It becomes a headache. Pushback builds. Projects quietly die.
Stop Saying “Network APIs” to Business Buyers. Start Saying “Trust Layer.”
One of the strongest reframes in the conversation was about language.
Greg argued that “network APIs” is a term that makes eyes glaze over outside technical circles—especially with product owners, security leads, and business stakeholders.
But “trust layer” lands.
If you walk into a fintech, a bank, a healthcare provider, or any enterprise dealing with identity and fraud and say: “We own the trust layer,” people lean in. They understand the category instantly.
If you say: “We’d like to talk to you about network APIs,” they’ll likely respond: “Please talk to my developers.” And the developers will respond: “Okay… but how does this save me time or remove pain?”
So the framing matters—because it determines whether the right people engage, and whether you can make the value feel real.
The Hard Part: Switching Costs Aren’t a Footnote
I raised another issue that matters a lot in enterprise adoption: switching costs.
Even if network APIs are “better,” many of the use cases already have existing solutions. One-time passwords are the obvious example. People may complain about OTPs, but they understand them—and they trust them enough.
So the enterprise pitch can’t just be “this is more secure.” It has to address:
- Why change now?
- What do I gain that I can’t get with what I already have?
- How much complexity am I taking on (legal, procurement, compliance, integration)?
In many cases, it needs to be dramatically better—“10x better/cheaper”—to make the switch feel like a no-brainer. If it’s only 20–30% better, you’re in long-cycle enterprise decision-making territory. That’s not bad, but it’s reality.
AI Is Turning Developers into Conductors (and That Changes Everything)
The conversation also shifted into AI and how developer work is changing.
Zach’s take was grounded: AI isn’t “taking all jobs.” It’s a tool that removes boilerplate and frees developers to think more like product owners—focusing on outcomes, architecture, and product shaping rather than repetitive coding.
Greg used a metaphor I loved: developers are moving from being virtuoso musicians to being conductors.
You don’t need to be the best violinist anymore. You need to understand the whole orchestra.
But—and this is important—AI doesn’t magically make software deployable at scale. Greg gave a perfect example: you can generate a web app prototype in minutes, but that doesn’t mean it’s secure, scalable, maintainable, or ready for real users. Trust, guardrails, release management, and best practices become even more critical.
Which brings us back to telcos, and to “trust.”
If telcos want to be the trust layer in an AI-assisted world—where code is produced faster than ever—then consistency, reliability, long-term guarantees, and clear value matter more, not less.
Why Communities Matter More Now Than Before
The final point was quietly powerful.
In an era where companies are rolling out AI tools top-down (“Here’s the tool. Now be 3–10x more productive. Go figure it out.”), developers need spaces to compare notes, learn best practices, and understand what’s real versus hype.
That’s what developer communities do at their best. Not just content and conferences—signal, trust, guardrails, and peer learning.
And if telcos want network APIs to become real, they need to earn credibility in those spaces. Not by showing up with neon lights and ping pong tables, but by showing up with pain-killing solutions, low-friction onboarding, and a developer experience that respects the ten-minute decision window.
What I’m Taking Into MWC (and What Comes Next)
This conversation happened right as we head into Mobile World Congress in Barcelona, where the industry will talk—again—about network APIs, security, identity, and the future.
My takeaway is simple: we’re still speaking in telco language to a developer world that thinks in problems, not plumbing.
If we want adoption, we need to shift from:
- Capabilities → pain relief
- APIs → outcomes
- Network APIs → trust layer
- Announcements → usable sandboxes
- Roadmaps → ten-minute “try it now” experiences
And then we need to prove it, consistently, over time—just like CPaaS did.
Greg and Zach are hosting droidcon Paris on April 9, and I’m looking forward to continuing the conversation there with the people who live and breathe developer reality every day.
Because the bridge between telcos and developers won’t be built by slogans.
It’ll be built by solving real pain—fast.
Watch the video here: https://youtu.be/MkZTeCb2M7A