Rebuilding a live platform from the ground up without dropping a call.

XOIP ran its cloud telephony services on purchased "unified messaging" boxes. These telecom appliances connected carrier trunks, converted voicemail to email, and routed fax as PDF. A PHP web app sat on top. The system worked reliably, but years of patches had made it hard to change without breaking something else.

The limits showed up in three places. Straightforward product ideas were not feasible inside the purchased platform. New pricing could not be modeled. And the frontend translated the boxes' settings into scattered inputs and toggles, which did not help a small business owner who only wanted the phone to work.

The choice was to rebuild instead of keep patching. The old stack would not support the product XOIP wanted or the SME market it was targeting. The problem was replacing it underneath 50,000 active customers.

The rebuild also clarified who XOIP was for. Enterprise telephony depends on bespoke implementations, long sales cycles, and customers with in-house IT. XOIP was not set up to win that market and did not need to.

SME customers needed professional phone features such as call routing, voicemail, office hours, and number management. They did not want a telecom engineer's learning curve. The product needed to offer real control without requiring customers to understand the machinery underneath.

That SME-first choice made simplicity a product requirement. It shaped the product, design, and technical decisions that followed.

The team evaluated more configurable telephony platforms during the rebuild. They had every PBX feature, but that also meant every setting could interact with every other setting. A clean surface quickly led to a maze of configuration screens.

Asterisk solved the right problem. As an open-source PBX framework, it gave us programmatic control over call logic without imposing its own configuration model. Telephony logic could stay on the Asterisk gateways. Product logic, user management, billing, admin, and the Call Plan could live in Python with a React frontend.

The architecture gave the design room to work. The SME strategy required a simple experience, and that ruled out platforms that would impose their own complexity. Asterisk let us keep control of the product surface.

The legacy interface translated the unified messaging platform's settings directly into inputs, selects, and toggles spread across several pages. There was no useful organizing model. Customers had to understand the system's internals before they could configure it.

Asterisk made a different model possible. An incoming call is an event that moves through conditions and ends with an outcome. Every SME owner already understands the result: a call gets transferred, sent to voicemail, or answered with a greeting. The Call Plan uses that prior knowledge.

The legacy product bundled voice and fax on the same number and in the same subscription. Fax was once common in business. By the time of the rebuild, it mainly served legal and financial teams that still needed privacy and delivery proof. Most voice customers did not need fax at all.

The case for keeping them together was mostly inertia. The two products had different customers, usage patterns, value propositions, and messages. Mixing them weakened both. Supporting voice and fax on one Asterisk number also required extra codec work that the old appliances had handled for us. We split the portfolio into voice and fax product lines, each with its own subscription, pricing, and customer journey.

Customer research showed that usage volume, not features, drove the voice purchase. We created three tiers based on bundle size and per-minute rate. Heavy users got more included minutes at a lower rate, while occasional users could stay on a lighter plan. A free tier covered pay-as-you-go customers.

The migration was the part that could undo everything else. 50,000 active businesses relied on phone numbers printed on letterheads and listed on Google. They expected service to continue through a full platform replacement.

We phased the migration by product and usage. Each wave started with lower-activity accounts, which exposed product-specific edge cases before the most active customers moved. Both platforms stayed live throughout. That gave us a way to catch problems before they spread, even though there was no practical path back once the new experience was live.

The new platform was easier to use, and the expected wave of UX complaints did not arrive. The real disruption was passwords. We could not move credentials securely between systems, so every user had to set a new one. Advance notice, a clear migration email, and a follow-up made that manageable.

Existing customers kept their products and pricing. The migration was not the time to add new commercial terms to a new experience. Later campaigns moved customers to comparable products in the new portfolio when they were ready.

I now build AI voice agents, design multi-agent systems, and run evals. Looking back, this rebuild was practice for all of it.

Choosing Asterisk was a technical, design, and strategy decision at the same time. The strategy was to serve SMEs, not enterprise. That made clarity and simplicity non-negotiable, which ruled out platforms that imposed their own complexity. Asterisk gave us the control to let the product lead.

The useful skill is holding that chain of reasoning and acting on it quickly. AI tools now help small teams do more of that work. I had been building the same cross-disciplinary fluency for two decades. The XOIP rebuild was an early, high-stakes version of the work I do now: hold the whole picture, make the call, and ship it.