Makook

A merchant in Damascus sells on Instagram. Orders arrive as direct messages, stock is tracked in a notebook, and payment is arranged one conversation at a time. Then a busy day comes, an order gets lost among a hundred messages, and nobody can answer the only questions that matter: was it paid, was it shipped, did it arrive?

Makook is a Syrian market e-commerce platform that lets a merchant open a store, take orders, and get paid — with no technical skill and no credit card. I founded it, architected it, and I lead the Syrian team of developers and designers who build it with me.

Why an off-the-shelf platform doesn’t solve it

The obvious answer is to sign up for a global platform. That fails at the first detail. Those platforms don’t settle in Syrian pounds, don’t know the payment rails people actually use, don’t connect to a single courier inside the country, and ask for a monthly subscription on a credit card most of the market doesn’t have.

The hardest constraint isn’t technical, it’s commercial: Makook’s free plan is free permanently and takes no commission on sales. That one fact settles the architecture. Any design whose cost grows with every new store is impossible before a line is written.

What makes it hard

Almost all of the difficulty sits in the local layer.

• Payments are plural, and none of them is Stripe. The platform settles in SYP and accepts cards through Paymera, e-wallets such as Sham Cash, bank transfer, and cash on delivery. Each has a different failure mode and a different definition of the moment “the money arrived.” They sit behind one boundary, so a merchant sees one order state rather than five vendor-shaped ones.
• Delivery is plural too. Orders go out through Wadily, Aramex, or Yalla Go, through the merchant’s own couriers, or as in-store pickup. Same pattern: one fulfilment interface, several providers behind it.
• The system has to stay up regardless of what happens around it. Power cuts, connectivity drops, conditions change. The cloud architecture is built so a store’s availability doesn’t depend on the stability of its surroundings — an architectural decision, not a hosting choice.
• Multi-tenancy from the first line. Every store is isolated in its data, configuration, domain, and branding, while the whole thing runs as one system I deploy once. Tenancy, identity, and money were settled before the first feature, because those are the decisions that are expensive to reverse.
• Arabic-first, not translated afterwards. Right-to-left shapes the data model itself, not just the stylesheet.

How it’s built

A modular monolith: real boundaries between modules, no shared tables across them, one thing to deploy. A platform like this has a lot of surface area but doesn’t need independently scaled services on day one. It gets the discipline of separation without the operational cost of a distributed system, and the seams stay in place if a module ever needs to move out.

I don’t hand this system over and walk away. I run it: the support messages, the migrations, the incident at an inconvenient hour. Nobody tells me what the architecture broke — I find out myself, and that is what makes my decisions on client projects cheaper for them.

Where this is relevant to you

If you’re building a platform that has to work inside a specific market’s reality — its payment rails, its couriers, its currency, its interruptions — rather than around it, this is the same problem. The general shape transfers directly: one clean interface per capability, several local providers behind it, and a tenancy model settled before features.

Makook is a live product. The fastest way to evaluate this work is to go and use it.