Why a 500,000-User Telco Stopped Building Its Own App
Elena's national telco spent years and a real engineering budget building its own softphone on open source, and never controlled it.
She gave up the plumbing she was failing at, kept the experience that made her money, and cut operating cost by more than ninety percent.
Elena ran product for a large national telecom operator. Half a million users. A real engineering budget. The kind of company that, when it decides to do something, assumes it will succeed, because it always has.
A few years ago they decided to build and control their own communications app, their own softphone, the app that turns a phone or a laptop into a business phone line.
The logic felt obvious: we are big, we have the users, we have the money, we will hire the people, and we will own it end to end.
Why build it yourselves?
Control. That was the whole argument. We did not want to depend on anyone. So we went open source, because open source sounds like the ultimate control. The code is public, it is free, you can do anything with it. And we backed it with our own scale.
We thought, if anyone can pull this off, it is us. We have 500,000 users and the budget to hire a team. We hired a whole group around this app. Engineers, testers, release managers. We poured money and people into it for years. On paper, we were doing everything right.
And in practice?
We never really controlled it. That is the hard truth. We thought hiring people and owning the code would give us control. It gave us the appearance of control and the cost of control, but not the thing itself.
What broke?
Devices. The world has an impossible number of phones, tablets, laptops, operating system versions, headsets, networks. A communications app has to work on all of them, perfectly, because a call that drops is not a bug, it is a customer leaving.
We could never get our app compliant enough across all of those devices around the world. We would fix it on one phone and break it on three others. New operating system, everything breaks. New device, everything breaks.
With all those resources, you still could not?
That is the part that humbled us. Five hundred thousand users did not give us the truth. Money did not give us the truth. Hiring did not give us the truth.
Because this is not a problem you solve with size. It is a specialization. Making real-time voice and video work flawlessly on every device on earth is somebody's entire life's work. It was a side project for us, even with a team on it. We were amateurs with a big budget competing against people who do only this.
What did it cost you?
We started churning. Massively. Users left because the app was unreliable, and every euro we spent trying to fix it was a euro of pure cost with no return.
We had built the most expensive thing we had ever owned, and it was driving customers away. We were not in control. We were hostages to our own decision.
Bet the build on size and open source
500,000 users, a real budget, a whole team hired around the app, on the theory that owning the code meant control
Devices broke it, forever
fix it on one phone, break it on three others; new OS, everything breaks; massive churn, pure cost with no return
Switched to an open framework, not open source
Acrobits owns and masters the voice and video engine, so it works on every device, and it stays open to plug your own tools in
Cut operating cost more than 90 percent
the team, the firefighting, the broken release cycles gone; more control now than when they owned the code
What changed?
We went to Acrobits. And the first thing I had to unlearn was the word "open." We thought open source was the answer. It was not. The answer was an open framework. They sound similar. They are opposites in the way that matters.
Open source means the recipe is public, but nobody is accountable for the meal. You have to cook it, and fix it, and own every failure, forever. That was our nightmare.
An open framework means there is a finished, reliable engine that someone else builds, owns, and masters, and it is still completely open for you to plug your own things into. Acrobits owns their code, wrote their own voice and video engine, and because they do nothing else, it actually works on every device.
But you handed the core to someone else. Was that not a loss of control?
That is the paradox I had backwards. I gave up control of the plumbing, the part I was failing at anyway, and I kept control of everything that was actually mine: our web apps, our CRMs, our messaging. I gave up the control that was hurting me and kept the control that was making me money.
How they used Acrobits
The subscriber self-care portal went into a Web Tab. Usage, billing, plan changes, wired through the IPC SDK so a low-balance alert fires as a native badge on the app icon, not a buried email.
Their own CRM went into a second Web Tab with single sign-on. The one the retention team already lived in. When a flagged customer calls support, the account and churn-risk score are already on screen.
Neither took a vendor ticket or a roadmap slot. They built both themselves.
If you had to teach this to someone, what is the one idea?
Unified communications happens in the UI.
It is not a server-room product anymore. It is whatever sits inside the screen someone is already holding: calls, messages, billing, CRM, all in one place.
The web tabs and the IPC SDK are how you build your own version of that without waiting on anyone.
What they needed
- An engine that just works on every phone, tablet, OS version, and network, owned by people who do only this
- To stop being the unpaid maintainer of their own app, and lose the team, the firefighting, the broken release cycles
- Their own tools inside the app on their own timeline: self-care portal, CRM, messaging, added the day a customer asks
- White-label branding so the app is their brand, not a vendor's
- Active-user billing so they pay for the subscribers who actually use the app
Technical detail
Features that did the work
Open framework
a finished, reliable voice and video engine Acrobits builds, owns, and masters, still fully open for the operator to plug their own tools into. Not open source, where nobody is accountable for the meal.
Web Tabs
any web tool (self-care portal, CRM, messaging) renders as a native tab inside the dialer, with single sign-on, so it feels like one tool.
IPC SDK
web content in those tabs fires native behavior. A low-balance alert lands as a real badge on the app icon, not a buried email. Standard web code, native behavior.
White-label branding
the app carries the operator's brand, not Acrobits'.
Active-user billing
pay for subscribers who register and place a call, not every provisioned seat.
And the business?
We cut our operating cost on this by more than ninety percent. The entire team, the endless firefighting, the broken release cycles, all of that expense, gone. And the app finally just worked, on every device, because that was now somebody's specialty and not our side project.
Here is the irony: we have more control now than when we owned the code. When a customer wants their tool in the app, we add it ourselves, that day. We never wait on a vendor roadmap.
The experience, the unified communications our customers actually see and touch, all of it happens in the app, in the UI, and we shape it ourselves. We finally own the thing worth owning.
Size is not the same as expertise, and owning the code is not the same as having control.
Do not confuse open source with an open framework. One makes you the unpaid maintainer of your own problems. The other gives you a core that simply works, owned by people who master it, and leaves you free to build everything that makes you different. You do not want to own the plumbing. You want to own the experience. We learned that at the scale of half a million users, and the education was expensive.