عبدالله سنكر: كيف تحوّل فكرة تطبيق إلى MVP بأقل تكلفة؟

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

الخطوة ١: اكتب المشكلة في جملة وحدة

مو «تطبيق يجمع كل خدمات السيارات». الجملة الصحيحة تحدد مين يعاني، ومن وش، ومتى: «صاحب سيارة في الرياض يضيع نص يوم عشان يلقى ورشة يثق في سعرها». إذا ما قدرت تكتبها بهالوضوح، فأنت لسه ما وصلت لمرحلة البرمجة، وأي ريال تصرفه الحين يروح على تخمين.

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

الخطوة ٢: اختبر الطلب قبل ما تبرمج

قبل الكود فيه طرق رخيصة تعرف فيها هل المشكلة حقيقية، وكل وحدة منها تكلّفك أيام مو شهور:

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

الخطوة ٣: حدّد الرحلة الوحدة اللي لازم تشتغل

كل تطبيق ناجح له مسار أساسي واحد: المستخدم يدخل، يسوي الشي اللي جا عشانه، ويطلع راضي. في تطبيق حجز الورش مثلاً: يختار الخدمة، يشوف ورش قريبة بأسعار واضحة، ويحجز. هذا هو الـ MVP. التقييمات المتقدمة، ونقاط الولاء، والمحادثة الداخلية، والوضع الليلي، كلها تقدر تنتظر.

الطريقة العملية: اكتب كل الميزات اللي في بالك في قائمة، واسأل عن كل وحدة: لو شلتها، هل المستخدم يقدر يكمل الرحلة الأساسية؟ إذا الجواب نعم، تنتقل لقائمة «بعدين». عادةً القائمة تنقص للنص أو أقل، وهذا بالضبط المطلوب.

الخطوة ٤: اختر تقنية توفّر عليك مرتين

اختيار التقنية في النسخة الأولى قرار مالي قبل ما يكون تقني. هذي القرارات اللي توفّر فعلاً:

• كود واحد لكل المنصات: Flutter يخلّيك تطلع على آيفون وأندرويد من مشروع واحد بدل فريقين، وهذا يقلّل تكلفة البناء ووقت الإصلاح بعده.
• خدمات جاهزة للأساسيات: تسجيل الدخول، وقاعدة البيانات، والإشعارات لها مزوّدين معروفين مثل Firebase و Supabase، والدفع له بوابات جاهزة. بناؤها من الصفر في النسخة الأولى هدر.
• لوحة تحكم بسيطة: الإدارة في البداية تقدر تكون لوحة جاهزة فوق قاعدة البيانات، مو نظام مخصّص بعشرين شاشة.
• الأتمتة بدل البرمجة حيث تنفع: إشعار للفريق، أو رسالة ترحيب، أو تقرير يومي، تتركّب على أداة مثل n8n بساعات بدل أسابيع.

الخطوة ٥: ابنِ وأنت حاط حدود واضحة

اتفق مع المنفّذ على قائمة ميزات مكتوبة، ومدة، ومراحل تسليم تشوف فيها شي يشتغل كل أسبوع أو أسبوعين. أي فكرة جديدة تطلع أثناء البناء — وبتطلع — تنكتب في قائمة «بعدين» ولا تدخل إلا بقرار واعي. التوسّع في النطاق أثناء البناء من أكثر الأسباب اللي تحوّل ميزانية النسخة الأولى إلى ضعفها. واطلب إن الكود يكون في مستودع باسمك من أول يوم، عشان لو تغيّر المنفّذ لأي سبب ما تبدأ من الصفر.

الخطوة ٦ و٧: أطلق لعدد صغير، ثم قرّر

ما تحتاج إطلاق كبير ولا حملة إعلانية في الأسبوع الأول. أطلق لعشرين أو خمسين مستخدم من اللي كلّمتهم في الخطوة الثانية، وراقب أشياء محددة: كم واحد كمّل الرحلة الأساسية؟ وين وقفوا؟ كم واحد رجع بعد أسبوع؟ هذي الأرقام تقولك وش تبني بعدين أكثر من أي اجتماع.

بعدها القرار واحد من ثلاثة: تكمل وتضيف من قائمة «بعدين» حسب اللي طلبه الناس فعلاً، أو تعدّل الاتجاه لأن المستخدمين استخدموا التطبيق بطريقة ما توقعتها، أو توقف وأنت خسران أقل بكثير مما لو بنيت التطبيق الكامل من البداية.

على منصة أزهل الرقمية، يبني عبدالله عبدالرحيم بن سنكر الكندي تطبيقاته بـ Flutter لنفس منطق الخطوة الرابعة: كود واحد يعني تكلفة أقل وإصلاح أسرع. بس قبل أي تقنية، الفكرة اللي يمشي عليها بسيطة: النسخة الأولى مو نسخة ناقصة، هي سؤال تطرحه على السوق بأرخص طريقة ممكنة. وكل ميزة تضيفها قبل ما تسمع الجواب، تدفع ثمنها مرتين: مرة وأنت تبنيها، ومرة وأنت تشيلها أو تصلّحها.