Introduction: Designing for Confidence

In the early 2000s, enterprise connectivity in South Africa was constrained by the limits of traditional WAN architectures and service availability, among other issues regulatory and political. Star, Mesh and Hybrid topologies built with point-to-point leased line-based services were expensive, rigid, and difficult to manage or scale. Generally, the topologies were chosen because they were the existing options. Frame relay was common, but it too was generally sold as a collection of point-to-point or point-to-multipoint services. Corporate wide area networks were often managed entirely by internal resources or only partially outsourced, including routing equipment and contractual relationships with providers. MPLS was emerging as a more flexible and beneficial alternative, and in 2001 a company named Citec became the first to offer it as a commercial product in the local market. They brought MPLS from technology to product, and by doing so, opened the door for a new generation of managed network services. Citec had taken a very structured and risk averse approach, legacy-minded in their design and execution. Their conservative approach had been aimed at replacing technologies like Frame Relay, rather than leveraging the benefits of MPLS.

By late 2003, our business had entered that market because our team had achieved a clear goal: to build an MPLS VPN product that would stand out by offering the benefits of MPLS over older technologies. We focused on enabling confidence, confidence for our sales teams, our partners, and our customers. We wanted our salesperson, when in front of the customer, to be able to offer something that made their next step feel easy, without second-guessing what was on the table.

When a customer sat with two proposals, ours and Citec’s at first but anyone else’s in principle, we wanted the choice to be clear. Our offer needed to be solid, valuable, practical, well-documented, and easy to understand. It had to be technically sound, commercially competitive, and operationally the lower risk for the customer. Moving from their existing WAN infrastructure to an entirely outsourced WAN built on a new technology was risk enough and required them to overcome high barriers to exit and entry alike. Our offering meant our sales team could lead the conversation with timelines and implementation planning, not discounting or feature rationalization. Our intention was for price to stop being the primary point of negotiation, because the value of our product to the customer was clear, greater, and with price more directly proportional to benefit than the alternatives. In many cases TCO was lower than that of the existing infrastructure which helped the customer to overcome the aforementioned barriers to exit.

To further support the salesperson in their task we established tiered pricing levels. One was standard list, another allowed room for negotiation at the salesperson’s discretion, and a third required management approval. This structure gave our team clear guidance and gave customers a clear sense of where the floor was, driving negotiation towards provisioned services, quantities, and benefits rather than price. If a customer tried to push past on price, they were essentially forced to make a choice: accept the “superior” product at a fair price or take more responsibility for less benefit with another provider. That rarely happened. The standardization of pricing made managing revenues and relative costs easier, put clearer boundaries in place and allowed the debtors team to understand the line items they would be working with clearly. The debtors’ team were able to notice an issue very quickly because uniformity means that exceptions are visible. Said another way, the customer experience relative to the invoicing of this product was easy to keep consistent and good, we understood that customers have requirements of every aspect of the product, not just its primary function, and a clear and accurate invoice means that their creditors team had its requirements met and fewer reasons for delay in payment existed. The cost to us was somewhat less too.

We also structured our pricing to consider total aggregate costs across the customer's entire WAN. We offered the benefit of scale while still allowing the simplicity of, specifically regarding the making of changes, pricing each branch independently. Bandwidth was provisioned in 64 Kbps increments, a figure that now seems small, but at the time was practical.

The greater the number of services, including the more aggregate bandwidth and sites a customer bought the product for, the lower the average per-unit of bandwidth price became. An economy was built into larger capacities at an accelerated rate. This approach rewarded customer growth, encouraged consolidation of spend, and gave our product a decisive advantage over Citec’s site-by-site pricing model requiring different pricing for different QOS classes. At the time technical people were saying things like “MPLS is of more benefit to the provider because it simplifies management” but we were able to form a product set which made sure there was a technology-based benefit to the customer, that buying MPLS from us was better than buying Frame Relay or point to point links, even from us.

While the product had to evolve with the technology, from the beginning, the platform was designed to support direct customers, resellers, and integrators. All customers, but saliently, resellers and integrators could define their own outbound QoS classes, build differentiated services, and brand the product and customer portal as their own, and at no additional cost. Some simply white-labelled it. Others transformed it into a deeply integrated offering aligned with their global strategies. Every reseller that succeeded with the product made it their own. Every reseller who bought our product was somebody who bought less or nothing from our competitors, primarily because our product was fundamentally different and wouldn’t interoperate with theirs.

One result of understanding our customers’ needs was a product with a built-in barrier to exit. Partners were invested, although our strong brand played a bigger role in this than our product did. Customers were committed. We elected instead of trying to control the channel rather to earn its trust. Where other providers clung to strict pricing controls and self-protective offerings, and tightly branded reseller structures, we offered strategic flexibility, and it worked. We signed every major international telco that entered the South African market.

This is the story of how that product came to life. How we balanced structure with openness, engineered the product as a platform, and created something that others could build on confidently, competitively, and in their own name.

And underneath that story, there were politics. The product function itself was still young, and its authority not yet fully established. The technical director had already begun work on enabling MPLS in the network, but by the time we began product development in mid-to-late 2001, nothing could yet have been delivered because the technology was still in early stages. He was under pressure to show progress.

In fairness, as the technical director for an internet and frame relay provider, MPLS may not have been his highest priority, but the resistance also reflected something deeper. This was a moment when product as a discipline was asserting itself, led by Rudi’s efforts to build formal processes, and that shift came with friction. Historically, engineering had set the direction. Now, market needs were becoming the driver. The business was maturing.

The tension would soon surface around the design itself, especially around the critical topic of Internet breakout, a challenge that would define the next phase of development.

Designing a Platform to build onto.

The MPLS VPN offering wasn’t built as a monolithic product and no product should be, there are too many interdependencies. It was engineered as a modular integrated platform, flexible enough to support diverse use cases and consistent enough to scale. Saliently, it was a central point to a larger system, and it was built for simplified expansion from day one.

At the time, the concept of service-driven MPLS was still new in South Africa. The only current competitor was focused on pure transport, more like them were coming. We approached it differently. From the beginning, the product was designed to accommodate services layered on top, security, monitoring, reporting, and in the future, voice, delivered with differentiated levels of quality and priority and facilitation in the customer portal for reporting and self provisioning.

Our earliest implementations relied on simple tagging and basic class-of-service mechanisms, traffic was either in the priority queue or it wasn't. QoS was available but was still going to develop quickly. Only a little later, customers would define traffic categories, voice, email, transactions, etc,  We quickly and simply made them aware of the concept of precedence rather than bandwidth guarantee. The network was initially built with Cisco 7500 Series routers which had a limitation in terms of QOS and allowed only one priority queue at hardware level, and we upgraded the nodes in proportion to demand and overcame that limitation early on.

Our service allowed customers to move both Corporate Private Network (MPLS) traffic and Internet traffic over the same access line. We achieved this by delivering the customer traffic over 802.1Q-tagged VLANs, each mapped to the appropriate VRF on the PE. The VLAN termination could be on the PE itself or on an intermediate device capable of routing to the required breakout or service.

This allowed us to offer a hybrid breakout model. Internet traffic could exit "centrally" via a designated interface between the WAN and the Internet, or locally to each branch office or site, depending on customer needs or preference. Centralised breakout through the core had been proposed as the default, using dedicated firewall modules installed in Cisco 6509 data centre switches. But the configuration required central bandwidth provisioning for all Internet traffic which, while easier for the engineering team, was something customers had resisted in discussions with product management. Branch-level breakout, supported via configuration on the PE, gave customers more control, more granularity, and greater cost efficiency. It meant that our product could solve problems for small businesses and bigger businesses with bigger budgets.

These choices reflected genuine market needs. Sales teams were hearing from customers who didn’t want their local internet access to be backhauled, at the time referred to as being "tromboned", over the local access loop. They wanted performance and flexibility, and we had to find ways to deliver both without compromising the stability of the core network.

Years later, as the product matured, QoS became more sophisticated. A predefined profile model was introduced, allowing customers to select from tiered service plans with fixed queue allocations and bandwidth shares. These were mapped via DSCP and IP precedence values into MPLS EXP bits, aligning with the queuing strategies across the core and PE-CE interfaces. While this theoretically reduced configurability, it offered better consistency, and our traffic management capabilities improved significantly. We allowed customers to choose either from the pre-determined set of Q.O.S structures or to modify the one they had chosen a little. Pre-determined structures made internal configuration processes "pre-configurable", making both implementation and training easier. It also gave the sales team more to negotiate with.

By that time, bandwidth was far less scarce. Customers were provisioning links in megabits, not kilobits. The demand had shifted from just getting connected to optimizing experience. Video, voice, and real-time applications were growing. SD-WAN wasn’t yet on the horizon though we were doing various of the things which later came with SD-WAN already. The foundation we built, layered, adaptable, modular, was ready for it.

Our goal early on was to enable control, transparency, and service differentiation in a way that matched what our customers and partners were trying to achieve. The platform evolved, but the intent never changed. Many of the features of the platform which included management consoles and specifically designed management and outsource services, were to enable the business priorities for our customers businesses, as opposed to being technical network service features.

Internet Breakout and the Architecture Debate

One of the most significant architectural decisions we faced was how to handle internet breakout, where and how internet-bound or sourced traffic would leave or enter the MPLS VPN. This was a pracitical rather than theoretical problem. Customers needed both intra-VPN connectivity and external internet access. The question was whether to centralise that breakout through a shared infrastructure in the data centre, or to enable it locally at each branch.

A centralised approach was initially favoured by the engineering leadership, and it presented a lot of potential for the business. The idea was to use dedicated modules in core data centre switches, Firewall Services Module (FWSM) in Cisco 6509’s, allowing all internet-bound traffic from customer sites to route through a common policy enforcement point. Technically clean, this model promised unified control and security posture. But it also introduced constraints. Bandwidth had to be provisioned centrally and a complex configuration on the switch still presented limitations for the customer. Theoretically, in our calculations, architecture became rigid requiring multiple firewall services simultaneously to function, and costs began to escalate at scale, notwithstanding that we were waiting for a software upgrade from Cisco which would make the architecture possible.

One alternative was localised breakout, allowing branches to access the internet directly over their local links, with appropriate segmentation and control. From a product perspective, this offered clear benefits. It made bandwidth planning more predictable and gave customers autonomy and flexibility. It also aligned with real-world needs: many customers simply didn’t want their Windows updates for all users in all locations traversing their central branch WAN access link. More saliently, it meant customers could budget per-branch or centrally, and some needed per-branch.

Product proposed a hybrid model. The engineering team solved the problem by specifying that MPLS traffic remained within the VPN, tagged and routed via PE configurations. Internet traffic, by contrast, was split out via virtual interfaces associated with the same physical link. One interface sat "inside" the MPLS VPN; the other was part of the global routing table. It was a pragmatic solution that met customer demand while remaining manageable for operations.

The proposal gained traction in part because the centralized solution required the "multiple virtual firewalls" feature in Cisco IOS that hadn’t yet been delivered, the 6509 firewall-module OS was still limited to a single virtual firewall instance. Delays in the firewall blade software, which was in EFT (Early Field Trial) at that time and unavailable to us, created a window for our approach to prove itself in the field.

Even later, when advanced firewall virtualization became viable, many customers preferred to continue with local breakout. It gave them flexibility and fit their usage models and gave us the opportunity to provide individual managed firewalls for a larger number of implementations. The centralized model never disappeared, it remained available for customers who wanted a more controlled, hub-and-spoke security posture, but it was no longer the only choice. It also used individual firewalls implemented in the Data Centre, rather than virtual firewalls configured on a firewall blade for a 6509 Workgroup Switch.

That tension, between engineering-driven elegance and product-driven customer needs focus, shaped much of what followed. The goal wasn’t to impose one model. It was to offer a platform that could support several.

With the benefit of hindsight, the political influences and conflict were what drove the business to deliver a better product. We are lucky to have very good leadership, and we worked in an environment where the best idea won rather than necessarily that of the most senior person in the room. This ethos created a product that was very competitive in the market and years later we would acquire the business which had been Citec in 2001, although not specifically as a direct result of our MPLS product. The product range would become a very healthy revenue stream, bringing in hundreds of millions each month and creating opportunities for revenue and other growth every day of its existence.

Speaking Two Languages

As we defined the MPLS VPN product, one of the most significant engineering and product alignment efforts lay in how we spoke about the products and features. Internally, we were building something complex: VRFs on PE routers isolated customer traffic; OSPF working in conjunction with IS-IS or static routing was used to establish CE-PE routing domains and .1q trunks; DSCP values determined QoS class mappings to COS classes; and PBR (Policy-Based Routing) let us direct traffic differently based on destination or source.

But we knew this language wouldn’t land with most of the people we needed to reach. The product wasn’t going to succeed if it was explained using configuration syntax, technical jargon or routing diagrams. We had to reframe it, describe it in terms that matched customer objectives and commercial outcomes, language customers would use to describe their own needs.

For example:

    A VRF became a VPN connection, a secure, isolated link between a branch and the cloud.

    PE-CE routing wasn’t framed in terms of OSPF adjacency or redistribution strategies, it was “dynamic routing,” or in some cases, “customer-managed routing,” depending on the handoff model.

    QoS classifications, based on DSCP or IP precedence, became “Realtime”, “Business Critical”, and “Best Effort” service classes, each tied to real traffic types like voice, Electronic File Transfer, and general browsing.

    A .1q trunk was used to separate internet and MPLS traffic over the same physical line became “Shared access line”, the ability to run both secure VPN traffic and internet breakout over a single circuit.

The hosted firewall blade option was never implemented, the technical, scalability, and product limitations ruled it out.  The capability it was intended to provide in MPLS VPN’s was achieved the same way as the shared access circuit, using trunks from the 6509 to a PE router.  The centralised breakout was named a “hosted node”, or “hosted breakout” depending on what the customer wanted to use it for, whether they were consuming services in the data centre or whether they intended to consume services elsewhere. That would later evolve in SD-WAN style to a “Third Party Service Link”.

Each of these translations required careful negotiation between the network team and product. The goal was not to obscure the technology but to wrap it in language that allowed sales, resellers, and even procurement managers to understand what they were getting and why it mattered.

This effort improved communication and also shaped how the product evolved. Once the vocabulary was set, it provided a framework for documenting, selling, training, and expanding the platform. We weren’t describing a router configuration, we were offering secure access, controlled prioritisation, local internet breakout, and managed routing policies.

And because that abstraction layer was rooted in real implementation detail, it gave the product the depth and made it intuitive for the customer, even for complex deployments. The terminology was customer-facing, but the engineering underneath it remained robust, consistent, and scalable.

Clarity, Conviction, and Customer Fit

This was a story of compromise with boundaries: being clear about what we were willing to adjust, and what we insisted on delivering. It was an MVP but not one in the minimalist sense, one that barely worked, pushed to market to see what stuck. It was something else entirely, a product deliberately shaped to meet real requirements, both internal and external, both commercial and technical.

Internally, we recognised that our sales team wasn’t just selling a network. They were selling certainty. So we gave them structure: clear pricing, strong differentiators, and a product they could explain in practical terms. We trained them not just on feature lists, but on the decision points that mattered to customers. We extended that clarity into our billing systems, our documentation, and our support structures. Even finance teams, who weren’t expected to know what DSCP or QoS or VRF meant, were given explanations that made sense in their own language. If someone needed to know how a COS class mapped to an invoice line item or why traffic prioritisation mattered on a 128 Kbps link, they got an answer they could actually use.

Technically, we made decisions that balanced capability with usability. Internet breakout was solved not by waiting for ideal IOS features, but by working with what we had: virtual interfaces, ACLs, and policy-based routing. QoS was designed to accommodate full DSCP range for those who needed it, and a simplified profile structure for those who didn’t. We built with deliberate flexibility, because customer needs were rarely uniform, and because our ability to meet those needs was the product.

And yes, there was friction. Competing priorities, entrenched mindsets, slow-moving dependencies. But those weren’t problems to be avoided, they were part of the landscape. Every delay forced a workaround. Every technical limit shaped a better, more resilient approach. Product development isn’t theory. It’s everything: engineering, politics, documentation, operations, and language.

The result? What started as a single network product became the core of a platform that generated more than R4.5 billion in revenue over a decade, and made us the market leader. That didn’t happen because of a clever idea. It happened because of deliberate strategy, real execution, and relentless alignment with what our customers, and our people, actually needed.

in My Work