Mahmoud Abdel-Fattah does not introduce himself as a CTO. Or a product leader. Or even an entrepreneur.

He calls himself a builder.

Titles, he says, put people in boxes. Building requires fluidity. At different moments he needs to think like a CTO, a product leader, or a founder, and he moves between those modes as the situation demands. The throughline is not the role. It is the instinct to build.

That instinct surfaced early. And it never left.

Asked when technology became central to his life, Abdel-Fattah does not point to a funding round or a job title. He goes back nearly three decades.

At ten years old, he was writing software using Clipper and dBase. A small project, but something clicked. “That’s when the builder inside me woke up,” he says. Tech was no longer interesting. It was the only way he knew how to keep building.

His relationship with technology stretches even further back than his first funded startup, which came more than 15 years ago. As a teenager, he assembled computers, experimented constantly, and tried to understand how things worked. Some experiments were entrepreneurial in the loosest sense. Selling copied Windows 98 CDs became an early lesson in how technology could generate value.

It was not polished. It was not structured. But it was formative. The pattern was clear long before the career was.

When the conversation turns to domain experience, Abdel-Fattah pauses. He has worked across SaaS, AI, AdTech, FinTech, and marketplaces. But one stands out.

Marketplaces shaped his mindset the most.

They force systems thinking. Supply and demand. Incentives. Trust. Operations. Technology. Change one element and the entire equilibrium shifts. You cannot optimise in isolation.

He sees marketplaces everywhere now. Even AdTech, he argues, is a marketplace at its core. Advertisers on one side, publishers on the other. That lens influenced every product he built afterwards. Think in systems first. Then optimise.

Pressed on how his early roles prepared him for founding companies, he is clear that the entrepreneurial instinct came first.

Before his first significant startup, BKAM, he operated mostly alone. Building solo meant freedom, but it also meant limited exposure to teams and structured environments.

Joining eSpace marked a shift. It was his first formal product role. There he learned how teams function, how organisations are structured, and how to build within systems larger than himself.

Then came Careem in early 2016, during a period of intense growth. Being inside a company scaling that quickly forced reflection. What had worked in his earlier ventures. What had failed. What he would never repeat.

Those reflections became a mental checklist. When he later co-founded Cartona, he applied it deliberately.

On the question of Cartona’s origin, Abdel-Fattah frames it simply: fix inefficiencies in traditional B2B retail distribution and empower wholesalers.

The initial focus was straightforward. Make ordering and discovery easier in a fragmented market. As the company gained meaningful share, the product expanded. POS tools. BNPL. Group ordering.

But the expansion was not random. It followed real usage.

Throughout, they stayed asset-light. They consciously avoided entering logistics. That restraint allowed them to scale without distorting the core marketplace model.

Cartona eventually served 35,000 retailers and reached $60 million in GMV. But the harder decisions were not about growth metrics.

They were about what not to build.

Asked about the toughest decisions as Co-Founder and CTO, he does not cite infrastructure or scale events. He talks about restraint.

Engineers, he says, are wired to add complexity. Structure feels like progress. But often the real discipline is subtraction.

The emotional challenge at Cartona was usability. Many retailers had limited technical literacy. Not limited intelligence, he clarifies, but limited familiarity with smartphones, apps, and digital workflows.

The team kept asking: can someone who has barely used an app beyond calls and messaging place orders comfortably here?

Every extra tap mattered. Every icon. Every label.

Designing a powerful marketplace that remained radically simple was not just a UX challenge. It was a responsibility. That experience reshaped how he thinks about inclusive technology.

When asked what investors look for in tech-driven startups, Abdel-Fattah avoids generalities.

Most investors, he says, focus on business growth. Some dig into technology. Others follow trends.

The serious ones rarely obsess over architecture diagrams. They look at the team. Has this technical leadership built reliable systems before? Do they demonstrate sound judgement?

Trust in the team matters more than the tools.

Abdel-Fattah has led engineering and product teams serving more than 60 million monthly users and handling billions of requests. Yet his definition of scalability is unfashionable.

It starts with simplicity.

He recalls powering native ads for major global platforms with a team of around ten engineers and product leaders. Ten exceptional people. Monthly AWS costs were roughly $4,000.

At the time, others boasted about headcount and cloud spend. He saw those as vanity metrics.

Real scalability shows up in small teams, low operational costs, and systems that do not require heroics to keep running.

Complexity is not a badge of honour. Efficiency is.

When the conversation shifts to his newer ventures, including Granite Holding and UPFRONT, Abdel-Fattah is candid about how much his approach has evolved.

Technology moves quickly. What was best practice three or four years ago may already be outdated.

For Granite and UPFRONT, he chose a completely different technology stack than the one used at Cartona. Not because the old stack was wrong, but because the context had changed.

He is less emotionally attached to past decisions now. He optimises for adaptability, speed, and learning, not theoretical perfection.

Asked about building Egypt’s leading money market fund app at Granite Holding, he shifts from code to regulation.

Fintech’s hardest problems are rarely technical. They are regulatory ambiguity, compliance, auditability, and alignment with authorities.

Then there is trust.

You are asking users to transfer their money into your product and trust you almost like a bank. That psychological barrier is significant. Overcoming it required transparency, strong safeguards, and patience.

Technology enables the product. Trust sustains it.

On the topic of building multiple products in parallel, including ZIDO and PodPulse, he is unusually direct.

“It’s a bit like throwing darts,” he admits.

If he likes an idea, believes it is genuinely different, and sees that it can be built quickly, he will try it. Side projects allow him to experiment with new technologies in ways large, long-running ventures do not.

Interestingly, he often learns more from the smaller experiments than from the bigger companies.

Risk, in small doses, sharpens judgement.

Asked how he balances speed with maintainability, Abdel-Fattah challenges the framing.

He does not believe in “long-term” in the traditional sense. The only true long-term element is the core, the foundational principles and key architectural decisions.

He spends most of his energy getting those right.

Once the core is solid, everything else can move quickly. Launch. Learn. Iterate. Speed and maintainability are not opposites if the foundation holds.

When the discussion turns to AI, he is pragmatic.

AI allows teams to ship more features faster. That is real leverage.

But it also inflates expectations. Stakeholders may assume everything can now move at AI speed. In reality, judgement, data quality, integration complexity, and problem framing still matter.

The CTO’s role shifts from hands-on implementation to boundary-setting. Deciding what should move fast. What should not. And where AI genuinely adds value.

Asked about common early-stage mistakes, Abdel-Fattah divides them into product and technology.

On the product side, founders fall into the feature trap. They keep launching features and drift away from their core value.

On the technical side, teams over-optimise for scale before earning it. They design for a million users before serving ten. They chase trends to signal sophistication.

In both cases, activity gets confused with impact.

Finally, when asked what advice he would give to Egyptian and Arab founders aiming to compete regionally and globally, his answer is blunt.

Sell first, then build.

Many startups do not fail because their products are weak. They fail because they cannot sell. Impressive technology means little if no one is paying for it.

Learn to sell early. Or find a co-founder who can.

Real demand comes before great code.