ما بنيناه ولماذا
أكثر من 12 تطبيقاً بنيناها ونشرناها ونصونها على App Store و Google Play، تغطي التعليم والتجارة والعقارات وإدارة العمل المؤسسي والمحتوى.
التحدي
الوضع التشغيلي كما وجدناه قبل أن نكتب سطراً واحداً.
بناء التطبيق ليس الجزء الصعب — البقاء على المتجرين هو الصعب.
التطبيق يُرفض لأسباب لا تُذكر بوضوح في المراجعة. وتحديث نظام التشغيل السنوي يكسر مكتبة فيتعطّل التطبيق لدى المستخدمين. وتتغيّر سياسات المتاجر فيُطلب امتثال جديد خلال مهلة محدّدة وإلا سُحب التطبيق. وشهادة التوقيع تنتهي فتتوقف التحديثات.
كل هذا يحدث بعد التسليم — وهو تحديداً ما تتوقف عنده أغلب الشركات.
قبل
- تحديث نظام التشغيل السنوي يكسر مكتبة فيتعطّل التطبيق
- تغيّر سياسات المتاجر يهدّد بسحب التطبيق خلال مهلة محدّدة
- حسابات النشر وشهادات التوقيع خارج يد العميل
بعد
- تطبيقات مستمرة منذ سنوات عبر تحديثات توافق دورية
- امتثال متابَع يُبقي التطبيقات حيّة على المتجرين
- ملكية كاملة للعميل على حساباته وتطبيقاته
كيف عملنا على هذا النظام
المسار نفسه في كل مشروع نبنيه — يتغيّر محتواه لا ترتيبه.
تحليل العمل
نجلس مع من يستخدم النظام يومياً، ونرسم المسار الفعلي بكل استثناءاته — وهي غالباً سبب تعثّر المشاريع لاحقاً.
تصميم المعمارية
نموذج البيانات ومصفوفة الصلاحيات ونقاط التكامل وسلوك النظام تحت الحِمل — تُحسم قبل أي واجهة.
التطوير
بناء على مراحل قابلة للاستخدام. كل مرحلة تدخل الخدمة عاملةً، فيُصحَّح المسار مبكراً وبكلفة أقل.
التكامل
ربط النظام بما حوله — محاسبة ودفع وجهات خارجية — بطبقة لا تنكسر عند أول تعطّل في الطرف الآخر.
التحسين والتشغيل
قياس الأداء تحت حِمل حقيقي، ثم تشغيل ومراقبة وصيانة تمتدّ بعد التسليم لا تنتهي به.
الحل بوحداته
ما بنيناه فعلاً، مفصّلاً بالوحدة لا موصوفاً بعبارة عامة.
أكثر من 12 تطبيقاً منشوراً على المتجرين، تشمل:
| المجال | التطبيقات |
|---|---|
| التعليم | تطبيق منصة اختبارات وطنية · تطبيق تدريب على اختبارات القبول الطبية · تطبيق مكتبة رقمية |
| التجارة | تطبيقات متاجر إلكترونية متعددة بتصفّح ودفع وتتبّع شحنات |
| العقارات | تطبيق منصة عقارية بالبحث متعدد المعايير والخرائط |
| إدارة العمل | تطبيق أتمتة المهام المؤسسية · تطبيق إدارة الورديات والموارد البشرية (أوروبا) |
| المحتوى | تطبيقات محتوى وبطاقات ومكتبات |
معظمها منشور على Android و iOS معاً، ومتكامل مع الأنظمة الخلفية التي بنيناها.
المعمارية التقنية
الطبقات كما بُنيت فعلاً في هذا النظام — من قناة المستخدم إلى البنية التي تشغّله.
واجهات برمجية أولاً
كل طبقة تتحدّث إلى ما فوقها عبر واجهة موثّقة، فإضافة قناة جديدة لاحقاً لا تعني إعادة بناء ما تحتها.
الأمان بين الطبقات
الصلاحيات تُفحص في طبقة الأعمال لا في الواجهة، وسجلّ التدقيق يوثّق كل عملية تغيّر بيانات.
أداء تحت الحِمل
العمليات الثقيلة تُدفع إلى طوابير خلفية، والقراءات الأكثر تكراراً تُخزَّن مؤقتاً، فتبقى مسارات المستخدم سريعة في الذروة.
التقنيات ولماذا اخترناها
نختار الأداة بحسب ما يجب أن تتصل به وما يجب أن تصمد أمامه — لا بحسب ما هو رائج هذا العام.
هندسة الخلفية Backend
اختيرت بحسب متطلّبات هذا النظام تحديداً، لا بحسب ما هو رائج.
اختيرت بحسب متطلّبات هذا النظام تحديداً، لا بحسب ما هو رائج.
اختيرت بحسب متطلّبات هذا النظام تحديداً، لا بحسب ما هو رائج.
اختيرت بحسب متطلّبات هذا النظام تحديداً، لا بحسب ما هو رائج.
طبقة الأعمال والواجهات البرمجية. اخترناه لنُضج منظومته في الصلاحيات والطوابير وترحيلات قواعد البيانات — وهي تحديداً ما تحتاجه الأنظمة المؤسسية طويلة العمر.
تطبيقات الجوال Mobile
قاعدة كود واحدة تُصدر تطبيقَي Android و iOS. توفّر كلفة بناء وصيانة نسختين، وتُبقي سلوك التطبيقين متطابقاً.
التكامل Integration
واجهات موثّقة تجعل النظام قابلاً للربط بما بعده. هذا ما يحوّل إضافة تطبيق جوال أو نظام ثالث لاحقاً إلى أسابيع بدل مشروع جديد.
الأنظمة المرتبطة Connected Systems
تحديات هندسية حللناها
القرارات التي اتُّخذت في هذا النظام تحديداً، وسبب كل منها.
واجهة خلفية واحدة لكل القنوات
— التطبيق والموقع ولوحة التحكم تقرأ من نفس REST API. القناة التي تقرأ من مصدر خاص بها تُنتج أرقاماً متضاربة، وهو أسوأ أنواع الأخطاء لأنه لا يظهر كتعطّل بل كعدم ثقة.
النشر على حسابات العميل لا حساباتنا
— التطبيق ملك العميل بالكامل بما فيه حساب المطوّر وشهادات التوقيع. الحساب المملوك للمطوّر يحبس العميل معه، ونعتبر ذلك عيباً لا ضماناً.
تحديث التوافق السنوي بند تعاقدي لا خدمة طارئة
— إصدارات نظامَي التشغيل الجديدة تكسر مكتبات وتفرض متطلبات امتثال، والتطبيق غير المحدَّث يُسحب من المتجر. جعلنا هذا بنداً معلوماً في العقد بدل مفاجأة سنوية.
Flutter قرار صيانة قبل أن يكون قرار بناء
— قاعدة كود واحدة تعني إصلاحاً واحداً لا اثنين، وتمنع تأخّر إحدى النسختين عن الأخرى — وهو ما رأيناه يحدث كثيراً في المشاريع المبنية بتطبيقين منفصلين.
كيف نعمل
Flutter كخيار أول — قاعدة كود واحدة للنظامين، بتوفير يقارب 40% من زمن التطوير والصيانة، وضمان ألّا تتأخر إحدى النسختين عن الأخرى.
واجهة خلفية واحدة — التطبيق والموقع ولوحة التحكم تقرأ من نفس REST API، فلا تتضارب الأرقام بين القنوات.
RTL أصلي — الواجهات العربية تُبنى بالاتجاه الصحيح من الأساس لا بقلب واجهة إنجليزية.
النشر على حسابات العميل — التطبيق ملك العميل بالكامل، ويُنشر على حساباته هو لا حساباتنا. نتولّى إعداد الحسابات ومواد المتجر واجتياز المراجعة.
الصيانة بعد الإطلاق — تحديثات التوافق السنوية مع إصدارات نظامَي التشغيل، وتتبّع الأعطال، والامتثال لتغيّر سياسات المتاجر.
الأثر بعد التشغيل
ما تغيّر فعلاً في عمل العميل — لا ما وعدنا به قبل البدء.
- أكثر من 12 تطبيقاً حياً على App Store و Google Play
- تطبيقات مستمرة منذ سنوات عبر تحديثات توافق دورية
- تكامل التطبيقات مع الأنظمة الخلفية المؤسسية دون ازدواج بيانات
- ملكية كاملة للعميل على حساباته وتطبيقاته
الأرقام أعلاه تخصّ حجم نظام العميل الذي بنيناه ونشغّل بنيته، لا حجم أعمالنا نحن. ونلتزم باتفاقيات السرية، فنعرض العمق التقني دون أسماء العملاء.