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

XOIP had been running cloud telephony services on a stack of purchased "unified messaging" boxes — appliances from an older era of telecoms that handled the hard work of connecting to carrier trunks, converting voicemail to email, routing fax as PDF. On top sat a PHP web app. The whole thing worked, in the way that something held together with years of careful patches works: reliably until it doesn't, and impossible to change without breaking something else.

The ceiling showed up in three places at once. Product ideas that should have been straightforward weren't feasible inside the constraints of the purchased platform. New pricing strategies couldn't be modeled. And the frontend — a direct translation of the boxes' underlying settings into input fields and toggles — communicated nothing coherent to a small business owner who just wanted their phone to work.

The decision to rebuild rather than iterate came from a clear-eyed assessment: the old stack would never let us build the product we wanted to build or serve the market we wanted to own. The question was how to execute a full replacement underneath 50,000 active customers.

The rebuild wasn't just a technical project — it was an opportunity to sharpen who XOIP was for. The enterprise telephony market is a different game: bespoke implementations, long sales cycles, customers with in-house IT who can absorb complexity. XOIP was not going to win there and had no reason to try.

The SME market offered something more interesting: a large customer base that genuinely needed professional phone capabilities — call routing, voicemail, office hours, number management — but had no appetite for a telecom engineer's learning curve. The opportunity was a product that gave them real functionality without requiring them to understand how it worked under the hood.

That strategic choice — SME-first, simplicity as a feature, not a constraint — cascaded directly into every product, design, and technical decision that followed.

The team evaluated more full-featured telephony platforms during the rebuild — systems with every PBX bell and whistle available. The problem was that full-featured meant infinitely configurable, and infinitely configurable meant inevitably complex. You'd design a clean surface and then find yourself mired in settings screens with unforeseen interdependencies.

Asterisk solved the right problem. As an open-source PBX framework, it gave complete programmatic control over call logic — without imposing its own configuration model onto the product. Telephony logic could live on the Asterisk gateways where it belonged. Product logic, user management, billing, admin, and the call plan itself could live in Python with a React frontend where I could design exactly the experience we needed.

The architecture created the conditions for the design. That causality — strategy sets design imperatives, design imperatives influence technical choices — only happens when someone is fluent across the whole stack. It's the kind of outcome that requires holding all disciplines in one mind simultaneously.

The legacy interface was a direct translation of the unified messaging platform's underlying settings: inputs, selects, and toggles scattered across several pages with no organizing logic. Users had to understand the system's internals to configure it. That's the wrong relationship between a product and its customers.

The breakthrough was recognizing that Asterisk's flexibility made a different mental model possible. An incoming call isn't a settings object — it's an event that passes through a logical sequence of conditions and ends with an outcome. That framing is something every SME owner already understands intuitively: you've been transferred, sent to voicemail, or heard a greeting. The Call Plan was built around that prior knowledge.

The legacy product bundled voice and fax on the same number inside the same subscription. That made sense when fax was a common business tool. By the time of the rebuild, fax usage had contracted to specific professional contexts — legal and financial — where privacy and delivery proof still mattered. Most voice customers had no fax requirement at all.

The internal argument for keeping them together was mostly inertia. The case for separation was cleaner: two different user bases with almost no overlap, different usage patterns, different value propositions, different messaging. Mixing them would dilute both. The extra engineering effort required to make dual voice/fax on the same Asterisk number reliably handle codec negotiation — work the old appliances had done but the open-source community hadn't prioritized — made the separation argument easier to win. We split the portfolio into a voice product line and a fax product line, each with its own subscriptions, pricing, and customer journey.

Within the voice line, the key insight from customer research was that usage volume — not features — drove the purchase decision. Three tiers emerged, differentiated by bundle size and per-minute rate: heavy users gravitated toward higher subscriptions with larger inclusive minutes and lower per-minute costs; occasional users toward lighter plans. A free tier covered pay-as-you-go customers, with upgrade prompts tied to new features as they shipped.

The migration was the part of the project that could have undone everything else. 50,000 active customers — businesses whose phone numbers are on their letterheads and their Google listings — expecting uninterrupted service through a complete platform replacement.

The approach was phased by product type and usage level. Each wave started with lower-activity accounts in a given product segment, which gave us the ability to surface any product-specific edge cases before migrating the most active customers. Both platforms stayed live throughout — a problematic migration could be caught before it propagated, though practically speaking there was no path back once the new experience was live.

The experience on the new platform was demonstrably better. The complaints we anticipated — users resistant to a new UX — didn't materialize at the scale we'd prepared for. The one genuine disruption was passwords: we couldn't migrate credentials securely across systems, so every user had to set a new one. Careful email sequencing — advance notice, migration trigger, follow-up — made this manageable.

Existing customers kept their original products and pricing. The migration wasn't the moment to ask them to absorb new commercial terms alongside a new experience. Over time, targeted campaigns moved users to comparable products in the new portfolio — on their terms, at their pace.

Looking back at this project from where I work now — building AI voice agents, designing multi-agent architectures, running eval systems — what strikes me most is how much this rebuild was practice for exactly that.

The most consequential decision in the project — choosing Asterisk as the telephony platform — wasn't a technical decision or a design decision or a strategic decision. It was all three at once, legible only to someone holding all three simultaneously. The strategy (serve SMEs, not enterprise) set the design imperative (clarity and simplicity as non-negotiable). The design imperative ruled out platforms that would have imposed their own complexity model. That left Asterisk, which gave full programmatic control and let the design lead.

That chain of reasoning — and the speed at which it can be executed — is the skill that AI tools are now compressing whole teams to produce. The difference is that I've been building that cross-disciplinary fluency for two decades, not acquiring it from a tool. The XOIP rebuild was an early, extended, high-stakes version of the work I do now — and the connective tissue between then and now is the same: hold the whole picture, make decisions that no single specialist would make, ship things that feel inevitable in retrospect.