What Semiconductor Design Taught Me About Building Software Platforms

The career path nobody predicted

I spent a decade designing wireless chip IP before I wrote a line of SaaS code. People in the CX industry sometimes ask why I think about customer experience so differently. The answer is not a pivot story. It is not a moment of inspiration on a whiteboard. It is the accumulated weight of twenty years building systems where failure is expensive and abstraction is survival.

When I tell people the sequence — internet kiosks in Luxor, telecom infrastructure, cryptography for banks and military, semiconductor IP, ARM's infrastructure compute programs, and then a customer experience platform — the reaction is confusion. These do not sit on the same career ladder. There is no template for this path.

But the connection is not accidental. It is architectural. Each layer built on the last. The core lesson is this: semiconductor design is the discipline of building layered systems with clean interfaces and strict governance — and that discipline transfers directly to building software platforms that need to scale, compose, and endure.

The layers beneath the layers

I started building things at twenty. Luxor Instruments was an internet solutions company in Upper Egypt — internet kiosks, provisioning, and billing software for hotels in Luxor Governorate. This was 2003. Most of Egypt's tech ecosystem did not exist yet. I was simultaneously working as a network design engineer at Telecom Egypt, designing and maintaining landline telephone infrastructure. Running a startup while working full-time at the national telecom company. That pattern of overlapping commitments would define my career.

After Luxor, I spent five and a half years at ComSpots, building cryptography and information security solutions for banking, public safety, and military sectors. Five and a half years of building systems where a security failure is not a bug report — it is a breach that compromises financial infrastructure or national defense. That period is why the word "governance" in my vocabulary is not marketing language. It comes from building systems where governance is the architecture, not a compliance checkbox added after the fact.

Then came Silicon Vision in Cairo — semiconductor design. Hardware and software solutions for IoT, multimedia, and industrial applications. I helped establish the product engineering and program management capabilities to develop system-on-chip solutions. In 2015, Synopsys — a global EDA giant with a market cap north of fifty billion dollars — acquired Silicon Vision's Bluetooth Smart IP. The client list had included Intel and Sony. That acquisition validated something important: globally competitive deep tech could be built from Egypt.

From Silicon Vision, I moved to ARM Holdings in Cambridge. Six and a half years in the Systems Group, managing cross-functional, globally distributed teams delivering ARM's most critical product lines — System IPs and Tooling for High-Performance Infrastructure Compute, Client Compute, Automotive, and IoT Compute. I was not designing individual chips. I was managing the delivery of the infrastructure layer that the entire computing industry runs on.

And then, in July 2016 — while still at ARM — I co-founded Tactful.

The overlap nobody talks about

This is the part most founder stories skip. I did not leave ARM to start Tactful. I built Tactful inside the margins of my ARM schedule — evenings, weekends, the hours between — until it was real enough to demand all of me. That took five years.

From 2016 to 2021, I ran both. A demanding program management role at one of the most important technology companies in the world, and a CX platform being built from scratch in Cairo. I did not leave ARM until October 2021, five years into Tactful's life.

Patience is not a value I chose. It is what the work required. Semiconductor culture teaches you that. You do not ship a chip in a sprint. You do not abandon a proven architecture because something new is exciting. You build until the foundation is solid, and then you build on top of it.

That patience — the willingness to invest five years of parallel effort before going full-time, the willingness to invest five million dollars in R&D before the market caught up — came directly from hardware culture.

How chips are designed

A modern processor is not designed as a single monolithic block. It is designed as layers. Each layer has a defined interface — a contract — with the layers above and below it. The instruction set architecture tells the software what the hardware can do. The microarchitecture decides how the hardware actually does it. The physical design determines how the transistors are laid out on silicon.

At ARM, I worked on IP blocks — reusable components licensed to chip manufacturers worldwide. The discipline was extreme. Your IP block had to work with hardware you had never seen, in systems you could not predict, for applications that did not exist yet. The interfaces had to be right. The abstraction had to be clean. The contract between your layer and the next had to be unambiguous.

If your interface was wrong, it was not a bug you could patch in production. It was a silicon respin — months of delay, millions of dollars. You learned to get the interfaces right the first time.

The parallel to CX infrastructure

When I looked at the customer experience industry in 2016, I saw the same structural problem that computing had before standardised architectures emerged. Everyone was building monolithic solutions. A chatbot company built the conversation layer, the NLP, the integration layer, and the analytics — all in one tightly coupled stack. A ticketing company did the same. A quality monitoring tool did the same.

The result was the same as computing before ARM and Intel standardised processor architectures: fragmentation, incompatibility, and the inability to build anything complex on top of existing foundations.

What CX needed was not a better chatbot. It needed a layered architecture with clean interfaces between each layer. It needed what computing needed in the 1990s — infrastructure.

My career had been unconsciously preparing me for exactly this problem. Networking infrastructure at Telecom Egypt. Security architecture at ComSpots. Hardware IP design at Silicon Vision. Infrastructure compute programs at ARM. Each role taught me a different dimension of the same discipline: how to build foundations that other things can be built on top of.

Five lessons from chip design that apply to software platforms

1. Define the interface before the implementation. In chip design, you write the specification for the interface before you write a single line of RTL. The interface is the contract. The implementation is the detail. In software, most teams do the opposite — they build the feature first and figure out the API later. This creates tight coupling and brittle integrations. At Tactful, every new layer starts with the interface spec. What does this layer expose? What does it consume? What is the contract?

2. Abstraction is not optional. A processor core does not know what operating system will run on it. An ARM Cortex-A core runs Linux, iOS, Android, and RTOS equally, because the ISA provides a clean abstraction boundary. In CX, your resolution brain should not care whether the customer came in via WhatsApp or voice. The channel layer should abstract that away. If your AI agent needs to know which channel the customer used to decide how to respond, your abstraction is leaking.

3. Governance is architecture, not policy. In chip design, power management is not an afterthought — it is designed into the architecture from the beginning. Clock gating, power domains, voltage scaling — these are architectural decisions, not policies bolted on later. In CX, governance works the same way. If your AI can take actions — refunds, cancellations, escalations — the governance for those actions must be in the architecture, not in a compliance review after deployment. I learned this not just from chip design but from five and a half years building cryptographic security for banks and military. When I say governance is foundational, I mean it in the way a security engineer means it: the system is either secure by design, or it is not secure at all.

4. Verification is 70% of the work. At ARM, we spent roughly 70% of our time verifying that the design worked correctly across all possible states. In software, most teams spend maybe 10% on testing. The result is predictable: software that works in the demo but fails in production. At Tactful, we invested heavily in automated testing and production monitoring precisely because hardware taught me that the cost of failure in production is orders of magnitude higher than the cost of verification before shipping.

5. Reusable IP is the ultimate leverage. ARM's business model was licensing IP blocks that other companies used to build their chips. The same IP block shipped in billions of devices. That is the power of designing for reuse. In CX, the equivalent is building platform capabilities that can be configured and composed by different customers for different use cases — without custom code for each deployment. When Silicon Vision's Bluetooth Smart IP was acquired by Synopsys, it validated the same principle: build something reusable, build it well, and the leverage compounds.

Why this matters now

The CX industry is at an inflection point. AI has made it possible to automate interactions at scale. But automation without infrastructure is chaos — the same way a processor without a standardised architecture is just a collection of transistors.

The companies that will define the next decade of customer experience are the ones that think about CX the way ARM thinks about computing: in layers, with clean interfaces, governed by architecture rather than policy, and verified before deployment.

I explored the infrastructure thesis in detail in The CX Industry Has a Tool Problem, and the story of why I came back to build it independently is in Why I Bought My Company Back.

Every SaaS founder I know came from product management, or sales, or another software company. I came from internet kiosks in Luxor, cryptographic security in the Gulf, chip design in Cairo, and infrastructure compute in Cambridge. That is not a weakness. It is why Tactful is built the way it is. Infrastructure first. Layers that compose. Governance by design. Depth before scale.

The path was not a pivot. It was an architecture.