تطبيق الويب بيتكلف كام فعلاً؟

اطلب من تلات شركات يسعّروا نفس تطبيق الويب، وهتاخد تلات أرقام الفرق بينهم يوصل لأربع أضعاف. أول حاجة بتيجي في دماغك إن حد فيهم بيبالغ في السعر. بس غالباً الحقيقة أمل من كده: هما بيسعّروا تلات مشاريع مختلفة، لأن الوصف ساب مساحة لتلات تفسيرات.

ودي الحاجات اللي فعلاً بتحرّك الرقم.

الأجزاء اللي المشتري بيشوفها

دي الشاشات. الكل بيسعّرها، وهي النص الأصغر من الشغل.

• كام شاشة مختلفة، وكل شاشة ليها كام حالة؟ القايمة شاشة واحدة؛ لكن قايمة فيها بحث، وفلاتر، وحالة وهي فاضية، وحالة خطأ، وحالة تحميل، وتقسيم صفحات، أقرب لست شاشات.
• قد إيه منها تصميم مخصوص، وقد إيه من مكتبة مكونات جاهزة (component library)؟
• محتاج يشتغل كويس على الموبايل، ولا بس يمشّي حاله عليه؟

الأجزاء اللي المشتري ما بيشوفهاش

حوالي 40% من أغلب المشاريع، والسبب المعتاد إن عرضين يبعدوا عن بعض.

تسجيل الدخول والصلاحيات. "اليوزرز يقدروا يسجلوا دخول" شغل نص يوم. "المديرين يشوفوا الفرع بتاعهم، ومديرين المناطق يشوفوا المنطقة بتاعتهم، والحسابات تشوف كل حاجة بس ما تعدّلش" ده شغل أسبوع، وبيلمس كل query في السيستم بعد كده.

تصميم البيانات (data modelling). لو ده اتعمل غلط فهو أغلى غلطة في السوفتوير على الإطلاق، لأن كل ميزة بعد كده بتورثه. ما بيبانش في الديمو، وبيحسم كل حاجة في السنة التانية.

ناحية الإدارة (الأدمن). لازم حد يضيف منتجات، ويصلّح أخطاء، ويرجّع فلوس طلبات، ويجاوب على "العميل ده ليه شايف سعر غلط؟". لو عرض السعر مافيهوش لوحة تحكم، يا إما هتفضل طول عمرك تطلب من مبرمج يشغّل queries على قاعدة البيانات، يا إما التكلفة مستخبية.

التعامل مع الأخطاء. إيه اللي بيحصل لما بوابة الدفع تاخد الفلوس وبعدين يحصلها timeout؟ السيستم اللي مالوش إجابة على السؤال ده مش خلصان، ده معمول عشان الديمو.

الأجزاء اللي محدش بيجيب سيرتها

سطر الصيانة ده هو اللي الناس بتجادل فيه، وهو اللي عمره ما بيطلع غلط. السوفتوير بيبوظ مع الوقت لأن الدنيا حواليه بتتغير — المتصفحات، والمكتبات، والـ APIs بتاعة الدفع، وقواعد الضرايب. والتطبيق اللي محدش لمسه سنتين مش مستقر، ده متساب من غير صيانة.

النطاق بيحرّك السعر إزاي فعلاً

النقلة من الـ MVP للتشغيل الفعلي هي اللي بتفاجئ الناس، وتقريباً كلها النص اللي ما بيبانش اللي اتكلمنا عنه فوق. والنقلة لـ"مترابط" معتمدة على الأنظمة اللي شغالة عندك أصلاً، مش على التطبيق الجديد خالص: API متوثّق شغل أيام، وسيستم مقفول شغل أسابيع.

إزاي تقارن عرضين مالهمش علاقة ببعض في الشكل

وحّدهم بأربع أسئلة:

1. ده فيه لوحة تحكم للإدارة؟ لو لأ، ضيفها — هتحتاجها.
2. الكود ملك مين، وهيتسلّم إزاي؟ ريبو وبيانات دخول، مش لينك مرفوع على سيرفر.
3. إيه اللي بيحصل في أول تلات شهور بعد الإطلاق؟ تصليح اللي هتلاقيه داخل في السعر، ولمدة قد إيه؟
4. إيه اللي مش داخل بشكل صريح؟ العرض الكويس بيجاوب على ده مكتوب من غير ما تسأل.

وبعدين قارن على تلات سنين، ومعاهم الاستضافة والصيانة. أرخص بناء كتير ما بيبقاش أرخص سيستم.

عرض السعر هو وصف لنطاق شغل ومعاه رقم. ولما رقمين يختلفوا جامد، اقرا الوصف، مش الأرقام.

تقدر تعمل إيه عشان تقلله بأمانة

• قلّل أنواع اليوزرز قبل ما تقلل المميزات. إنك تدعم تلات أدوار بيتكلف أكتر بكتير من دور واحد، وإضافة دور بعدين أسهل من إنك تشيل دور.
• استخدم مكتبة مكونات جاهزة. التصميم المخصوص لكل شاشة هو المكان اللي الميزانيات بتروح فيه. اصرف فلوس التصميم على الشاشتين اللي فارقين.
• أجّل الربط مع الأنظمة التانية. اطلق الأول، وبعدين اربط. الربط أسهل مع سيستم موجود فعلاً.
• اكتب الصفحة. صفحة واحدة بتوصف مين هيستخدمه، وأهم تلات حاجات هيعملوها، وأنهي أنظمة لازم يتكلم معاها، هتغيّر السعر بتاعك أكتر من أي فِصال.

أسئلة بتتكرر

ممكن ناخد سعر ثابت؟

لنطاق متحدد كويس، أيوه، ولازم تبقى عايز كده. أما "ابنولنا منصة"، فمافيش شركة أمينة تقدر — واللي بتعمل كده بتكون حاطّة المخاطرة جوه الرقم، وأنت بتدفعها سواء حصلت ولا لأ.

أرخص لو عملنا الموبايل في نفس الوقت؟

غالباً أيوه لو خططت له من الأول، وأغلى بكتير لو ضفته بعدين. ولو بتفكر في تطبيق موبايل بالذات، تكلفة الأبلكيشن بتتقسم بشكل مختلف.

نشتري حاجة جاهزة بدل كده؟

وارد جداً. اقرا سوفتوير مخصوص ولا جاهز كويس قبل ما تطلب أي حاجة.