من همزة — From Hamza
بداية كل شيء كانت محادثة. كنت جالساً مع مؤسس في الرياض — رجل ذكي، رؤيته واضحة، مستثمروه جاهزون للجولة القادمة.
That conversation stayed with me. Over 10 years building products at Salla, Barakah, and consulting for founders from Cairo to Dubai — I've watched the same technical patterns emerge, cause the same damage, and get ignored in the same ways.
That's why I started Mouthanna. Welcome to Issue #1.
— Hamza
─────────────────────────────
THE ARCHITECTURE DECISION THAT KILLS STARTUPS BEFORE SERIES A
I'll describe a company. Tell me if it sounds familiar.
They launched fast — smart founders, real market need, scrappy team. They hired an agency to get the MVP out. Under pressure, that developer made reasonable short-term choices: one database for everything, business logic scattered across API endpoints.
It worked. They got users. They raised pre-seed. They hired two more engineers.
And then something broke. Not in a dramatic way. In the slow, expensive way.
Features that should take a week take three. New engineers feel immediately lost. The founder starts hearing: "We need to refactor before we can build X."
By the time they reach me, they are six months from a Series A conversation, and their CTO (if they have one) is quietly panicking.
The root cause, almost every time: they built a monolith with no internal structure, and no one ever made the decision to change it.
THREE THINGS YOU CAN DO RIGHT NOW
1. Demand a complexity audit before your next sprint planning.
Ask your engineering lead: Where are the top five places in our codebase where a small change causes the most risk? This is a map. You need to know where the landmines are before you step on them during a fundraise.
2. Introduce one rule: no business logic in API routes.
When business logic lives directly in your API handlers, it becomes invisible and untestable. Moving it to a service layer — even gradually — creates breathing room.
3. Schedule a future features conversation.
Ask your engineers: If we wanted to add the feature two quarters out, what would break? The answer tells you more about your architecture health than any code review.
─────────────────────────────
MENA RADAR
1. Saudi fintech consolidation is accelerating — the winners will be infrastructure plays, not apps. Series A fintech money in 2026 is going to infrastructure.
2. Egyptian engineering talent is going remote at scale. The best engineers now have offers from European companies paying in dollars. You need either a competitive dollar rate, or a genuine equity story.
3. The AI wrapper startup wave is hitting MENA, and most of it will be dead within 18 months. If your moat is "we use AI," you do not have a moat.
─────────────────────────────
READER QUESTION
Q: When does a startup actually need a fractional CTO versus waiting for the right co-founder?
A: You need a fractional CTO the moment you are making product decisions that have architectural consequences. If you are pre-product, 4–6 hours per month is enough. If you have a product in market and are approaching seed, you likely need 1–2 days per week. The co-founder search should continue in parallel — but do not let that search be an excuse to fly blind on technical decisions right now.
─────────────────────────────
If you found this useful: forward it to one founder who needs it.
Book a free 30-min call: calendly.com/hamza-mouthanna/30min
mouthanna.io — CTO as a Service for MENA startups
— Hamza
Tech Lead @ Salla | Principal Engineer @ Barakah App | Founder, Mouthanna
Riyadh, Saudi Arabia