منتج SaaS في 12 أسبوعاً: ما يجب أن يكون صحيحاً قبل البناء

كل مؤسس يريد إطلاق منتج SaaS في اثني عشر أسبوعاً. بعضهم ينجح، ومعظمهم لا، والسبب ليس سرعة الفريق. السبب أن الاثني عشر أسبوعاً تُخطَّط كأنها مشروع بناء، بينما هي في الحقيقة مشروع حذف: ما الذي نستبعده حتى يصل المنتج إلى أول عميل يدفع؟

هذا المقال يشرح ما يجب أن يكون صحيحاً لتحقيق الاثني عشر أسبوعاً، وما الذي يدفع المشروع إلى عشرين، وكيف يبدو الأسبوع الأول والثاني عشر. النطاق المنشور لخدمتنا 25,000 إلى 35,000 ريال و12 إلى 20 أسبوعاً. الاثنا عشر هي الحافة الدنيا، لا الوعد الافتراضي.

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

إذا غاب شرط منها، فالمشروع ليس مشروع بناء. هو بحث. والبحث له ميزانية وزمن مختلفان. الخلط بينهما هو سبب النزاع الأشهر بين المؤسس والوكالة: الأول يظن أنه يشتري منتجاً، والثانية تبني ما طُلب منها حرفياً، والنتيجة منتج لا يستخدمه أحد.

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

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

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

قائمة «لن نبنيه» هي أهم وثيقة في المشروع. اكتبها في الأسبوع الأول، وعلّقها حيث يراها الجميع. أمثلة على ما يمكن تأجيله: تطبيق جوال، وتقارير متقدمة، ولوحة تحليلات مخصصة، وتعدد اللغات، وتكامل مع الـERP، وأتمتة الفواتير، ونظام صلاحيات معقّد، ودعم عملاء داخل المنتج.

التأجيل ليس إهمالاً. هو ترتيب. المنتج الذي يصل إلى أول عميل يدفع يعطيك معلومات لا تعطيها ستة أشهر من التخطيط. والنسخة الثانية تُبنى على ما تعلّمته، لا على ما تخيّلته. للمقارنة بين نموذج الاشتراك والترخيص، راجع معمارية SaaS متعدد المستأجرين بعد قراءة هذا المقال.

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

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

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

هل اثنا عشر أسبوعاً واقعية؟ نعم لمنتج بمسار واحد ودورين وتكامل دفع واحد. لا لمنتج متعدد الأدوار والتكاملات.

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

هل نبني تطبيق جوال مع النسخة الأولى؟ لا، إلا إذا كانت القيمة الأساسية لا تُقدَّم إلا على الجوال.

كم يستغرق الإطلاق الكامل؟ النطاق المنشور 12 إلى 20 أسبوعاً، ويعتمد على عدد الأدوار والتكاملات.

ماذا بعد الأسبوع الثاني عشر؟ قرار: توسّع، أو تعديل، أو إيقاف. القرار يُبنى على استخدام حقيقي، لا على رأي.

• Atlassian: Agile — دورات التسليم القصيرة وإدارة النطاق.
• web.dev: Web Vitals — معايير الأداء التي نختبر بها المنتج.
• اللائحة التنفيذية لنظام حماية البيانات الشخصية — ما يجب أن يدخل في النسخة الأولى.
• منصات SaaS — نطاقنا في البناء والتشغيل.
• تكلفة تطوير بوابة عملاء — مقارنة نطاق مشابه.