What Semiconductor Design Taught Me About Building Software Platforms

The career path nobody predicted

I spent more than fifteen years in hardware engineering before I wrote a line of SaaS code. People in the CX industry sometimes ask why I think about customer experience so differently. I never pivoted. A long run of building systems where failure is expensive and abstraction is survival just... accumulated.

Internet kiosks in Luxor, telecom infrastructure, cryptographic hardware in Riyadh, semiconductor IP at Silicon Vision, ARM Holdings' infrastructure compute programs, and then a customer experience platform. When I tell people the sequence, they look for the logic. There is no template for this path. But the connection is architectural. Each layer built on the last.

The layers beneath the layers

Luxor Instruments was an internet solutions company in Upper Egypt: internet kiosks for Nile cruise boats serving Luxor and Aswan. This was 2004. 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, though I did not know it then.

After Luxor, I spent five years in Riyadh building cryptographic hardware — encryption key generators, encrypted phones, fax encryption — for Saudi government agencies, through a connection from university. A security failure in those systems was never a bug report. It was a breach that compromised the communications infrastructure of the state. That period rewired how I use the word "governance." For me it was never marketing language. It came from building systems where governance was the architecture, where a compliance checkbox added after the fact meant someone had already failed.

Then came Silicon Vision in Cairo's Sheraton Valley — a semiconductor design house where I was brought in to rescue a failing fibre optics chip project for a major US telecom. I built the digital design and verification teams from scratch. The client list had included Intel, Broadcom, and Sony. Later, Synopsys — a global EDA giant — acquired Silicon Vision's IP portfolio, anchored by the Bluetooth Smart IP.

That acquisition validated something I think about often: globally competitive deep tech could be built from Egypt.

I moved to ARM Holdings in Cambridge after that. More than six 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 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 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.

Semiconductor culture teaches you this kind of patience. 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. Five years of parallel effort before going full-time, five million dollars in R&D before the market caught up. That willingness came directly from hardware culture.

How chips are designed

A modern processor 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. 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.

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.

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.

The result was fragmentation, incompatibility, and the inability to build anything complex on top of existing foundations. What CX needed was a layered architecture in CX with clean interfaces between each layer. It needed what computing needed in the 1990s: infrastructure. That recognition is what eventually became the infrastructure thesis.

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

What crosses over from chip design to software

The most important thing chip design teaches you is to define the interface before the implementation. In hardware, 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. Most software teams do it backwards. They build the feature first and figure out the API later, which 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?

Abstraction is the second thing that stays with you, and it stays not as a principle but as a reflex. 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. If your AI agent needs to know which channel the customer used to decide how to respond, your abstraction is leaking.

Then there is governance. In chip design, power management is designed into the architecture from the beginning: clock gating, power domains, voltage scaling. These are architectural decisions, not policies bolted on later. I learned this lesson twice. First from five years building cryptographic hardware for Saudi government agencies, where the system is either secure by design or it is not secure at all. Then again at ARM, from a different angle. If your AI can take actions like refunds, cancellations, or escalations, the governance for those actions must be in the architecture. A compliance review after deployment is too late.

The verification discipline is probably what separates hardware people from software people most sharply. 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. At Tactful, we invested heavily in automated testing and production monitoring precisely because hardware taught me what failure in production actually costs. That instinct eventually led to building 19 AI agents that simulate cross-functional review on every feature — the same discipline, applied through a different medium.

And reuse. 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. When Silicon Vision's Bluetooth Smart IP was acquired by Synopsys, it validated the same principle: build something reusable, build it well, and the returns compound. 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.

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.

Every SaaS founder I know came from product management, or sales, or another software company. I came from internet kiosks in Luxor, cryptographic hardware in Riyadh, chip design in Cairo, and infrastructure compute in Cambridge. That is why Tactful is built the way it is, and why I bought the company back when the opportunity came.

Three things I trust: layers that compose, governance by design, interfaces before implementation. That is what I know how to build, so that is what I build.

Frequently asked questions

How does chip design experience apply to software platforms?+

Semiconductor design teaches you to define interfaces before implementation, build in clean abstraction boundaries, and design governance into the architecture from day one — not as an afterthought. These disciplines transfer directly to platform engineering. At ARM, a wrong interface meant a silicon respin costing months and millions. That level of consequence rewires how you think about software architecture.

What is layered architecture in CX platforms?+

Layered architecture in CX is the principle that customer experience infrastructure should be built as distinct layers with clean interfaces between them — channels, resolution brain, action layer, system of record, and ops governance — rather than as monolithic point solutions. Each layer has a contract with the layers above and below it. This is the same architectural pattern that standardised computing in the 1990s.

What did Silicon Vision in Cairo build before Synopsys was involved?+

Silicon Vision was a semiconductor design house based in Cairo's Sheraton Valley. I joined to rescue a failing fibre optics chip project for a major US telecom company and went on to build the digital design and verification teams from scratch. The client list included Intel, Broadcom, and Sony. Later, Synopsys — a global EDA company — acquired Silicon Vision's IP portfolio, anchored by the Bluetooth Smart IP. The acquisition validated that globally competitive deep tech could be built from Egypt.

Why do ARM engineers think differently about software?+

ARM engineers spend roughly 70% of their time on verification — ensuring designs work correctly across all possible states. Most software teams spend perhaps 10% on testing. That verification discipline, combined with the habit of defining interfaces before implementation and designing governance into the architecture, creates a fundamentally different approach to building systems. You learn that skipping a step has consequences measured in months and millions, not hotfixes.