Engineering for the network Syria actually has
Average fixed broadband near the bottom of global rankings, electricity a few hours a day in much of the country, and Starlink in a regulatory gray zone. Here's how we design software for that — without patronizing the user.
The investment guides put it bluntly: Syrian fixed broadband averages around 4.6 Mbps — ranked 179th of 181 countries — while urban mobile manages a more respectable 22–26 Mbps. Electricity availability sits at 2–4 hours a day in many areas. If your app assumes a stable connection and a charged battery, it doesn't work in Syria. Ours have to.
The four rules we build by
- Offline-first is the architecture, not a feature. Local database as the source of truth, sync when the network allows, conflict resolution designed up front. The app must be fully usable through an outage and reconcile gracefully after.
- Payload budgets, enforced in CI. First load under 300 KB compressed for web; API responses paginated and delta-encoded; images served in modern formats at the exact rendered size. A budget that isn't enforced automatically is a wish.
- Battery is a resource like memory. Background sync batched on charge + Wi-Fi where possible; no polling loops; push over pull. On 4 hours of grid power a day, an app that drains 8% per hour gets uninstalled.
- Degrade by feature, not by failure. Decide explicitly which features work offline, which queue, and which honestly require a connection — and tell the user which mode they're in. Silent failure is the only unacceptable state.
The Starlink wildcard
Satellite internet is widely used through informal channels, and the communications ministry has signaled openness to regularizing it — enforcement so far has targeted smugglers rather than individual users, while formal licensing is worked out. If and when terminals are licensed, the bandwidth floor in underserved areas jumps dramatically. Until then, treat high-bandwidth users as the exception your architecture enjoys, not the baseline it requires.