منتج SaaS هو برنامج يستخدمه العميل عبر الإنترنت مقابل اشتراك دوري. الطريق الأقل خسارة إلى أول عميل يدفع يبدأ بإثبات أن الناس سيدفعون، ثم تبني أصغر نسخة تخدمهم. أما بناء منتج SaaS كامل ثم البحث عمن يشتريه فيجعلك تدفع ثمن كل ميزة قبل أن تعرف إن كان أحد يريدها.
يقدم هذا المقال اختبارًا من أربع مراحل يمكنك تنفيذه قبل كتابة سطر كود، مع علامة استمرار وعلامة توقف لكل مرحلة. الأعداد المذكورة هنا نقاط بداية نقترحها، وليست نتائج دراسات، فحدد أرقامك أنت قبل أن تبدأ حتى لا تفسر النتائج لصالح فكرتك.
طريقة اختبار الفكرة قبل كتابة الكود
| المرحلة | ما تفعله | علامة الاستمرار | علامة التوقف |
|---|---|---|---|
| 1. المشكلة | 10 إلى 15 محادثة مع أشخاص من الفئة المستهدفة | يذكرون متى حدثت المشكلة آخر مرة، وما كلفتهم من مال أو وقت | يقولون «فكرة جيدة» ولا يذكرون أي مثال |
| 2. الوعد | صفحة واحدة تشرح النتيجة والسعر | يقبل بعضهم خطوة ملزمة: اجتماع مع صاحب القرار، أو دفعة مقدمة | يطلبون إبلاغهم «عندما يصبح جاهزًا» |
| 3. الخدمة اليدوية | تقدم النتيجة بنفسك لعدد قليل من العملاء، بجداول وأدوات جاهزة | يعودون في الدورة التالية، ويطلبون استمرار الخدمة | يتوقفون بعد التجربة الأولى، ولو كانت مجانية |
| 4. أصغر نسخة | تبرمج الخطوة التي استهلكت أكبر قدر من وقتك يدويًا | يدفعون، ويستخدمون المنتج دون أن تذكرهم | يدفعون مرة واحدة ثم يختفون |
المرحلة 1: اسأل عن الماضي، وليس عن فكرتك
أقوى دليل مبكر أن يدفع الناس اليوم لحل المشكلة بطريقة سيئة: موظف، أو خدمة خارجية، أو يوم ضائع كل أسبوع في جداول. وإذا لم يكن أحد يدفع أو يبذل جهدًا، فأنت تحاول خلق عادة جديدة، وهذا أصعب وأعلى تكلفة.
لا تسأل «هل ستستخدم هذا المنتج؟»، لأن المجاملة تجيب عنك. اسأل عما حدث فعلًا:
- متى واجهت هذه المشكلة آخر مرة، وماذا فعلت؟
- كم كلفك ذلك من مال أو ساعات؟
- ما الذي جربته ولم ينجح؟
- من يقرر الشراء في شركتك، ومن أي ميزانية؟
يخصص كتاب The Mom Test لروب فيتزباتريك صفحاته لهذه المحادثات وكيف تتجنب الإجابات المضللة. وتحدث مع غرباء من الفئة المستهدفة، فأصدقاؤك سيشجعونك مهما كانت الفكرة.
المرحلة 2: اعرض الوعد والسعر
اكتب صفحة واحدة: لمن المنتج، وما النتيجة، وكم السعر الشهري، ومتى يبدأ. ثم اعرضها على من تحدثت معهم. مثال افتراضي: فكرة أداة تذكّر عملاء ورش السيارات بمواعيد الصيانة، بسعر 50 وحدة نقدية شهريًا. اطلب من أصحاب الورش الموافقة على التجربة في الشهر القادم بدفعة مقدمة.
طلب الالتزام يكشف ما لا تكشفه الأسئلة. فقد يقول لك صاحب الورشة إن الفكرة ممتازة، ثم يتردد عند أول طلب للدفع. هذا التردد معلومة مفيدة عن السعر أو الوعد أو الشخص الذي تحدثت معه.
المرحلة 3: قدم الخدمة يدويًا قبل برمجتها
نفّذ ما سيفعله البرنامج بنفسك لأول مجموعة من العملاء. في المثال الافتراضي السابق، أرسل رسائل التذكير يدويًا من جدول لمدة شهر. ستعرف ما يطلبه العميل فعلًا، وما يتجاهله، وأي خطوة تستهلك وقتك.
يدافع مقال بول غراهام «افعل ما لا يتوسع» (Do Things That Don't Scale) عن هذا الأسلوب: يقول إن المستخدمين الأوائل لا يأتون وحدهم، فعلى المؤسسين الذهاب إليهم. ويذكر كيف كان مؤسسو Stripe يجهزون المنتج للمستخدم في مكانه، وكيف كانوا ينفذون يدويًا وراء الكواليس بعض ما يبدو آليًا. الهدف أن تتعلم، وستتوقف عن العمل اليدوي بعدما تعرف ما يستحق البرمجة.
المرحلة 4: ماذا تبني في النسخة الأولى (MVP)؟
ابنِ الخطوة المتكررة التي يدفع العميل من أجلها، مع ما يلزم لتشغيلها فقط: تسجيل دخول، وصلاحيات أساسية، وطريقة للدفع. قلل الميزات، وحافظ على جودة ما يبقى منها. يتقبل العميل قائمة قصيرة أكثر مما يتقبل خطأ يفقده بياناته.
قبل أن تبرمج، تأكد أيضًا من أن منتجك يستحق البناء أصلًا. إذا كانت هناك أدوات جاهزة تحل المشكلة نفسها جيدًا لفئتك، فاقرأ مقارنة النظام الجاهز والمخصص بعين العميل، لأنه سيطرح السؤال نفسه عنك.
قرارات تقنية يصعب تعديلها لاحقًا
بعض القرارات صغيرة في البداية، وتغييرها مكلف بعد تراكم العملاء. ناقش هذه النقاط مع فريق التطوير من أول يوم:
| القرار | ما تسأل عنه |
|---|---|
| عزل بيانات العملاء | كيف نضمن ألا تظهر بيانات عميل لعميل آخر؟ تقارن إرشادات OWASP بين قواعد بيانات منفصلة وجداول مشتركة، فالأولى أقوى حدودًا وأعلى تكلفة تشغيل، والثانية تعتمد على دقة الضوابط |
| الباقات والأسعار | هل تُخزن كبيانات يمكن تعديلها من لوحة تحكم، حتى لا يصبح كل تغيير في السعر إصدارًا برمجيًا؟ |
| سجل الأحداث | هل نعرف من غيّر ماذا ومتى، عندما يسأل عميل عن رقم تغير؟ |
| حدود الاستخدام | هل توجد حدود لكل عميل، حتى لا يؤثر استخدام عميل واحد على الباقين؟ |
| تصدير البيانات | هل يستطيع العميل أخذ بياناته إذا غادر؟ قد يطرح المشتري هذا السؤال قبل الاشتراك |
كيف تحصل على أول دفعة؟
اطلب الدفع من أول عميل، حتى لو بسعر تجريبي محدد المدة. الاستخدام المجاني لا يختبر أهم فرضية عندك. ولست مضطرًا إلى بناء نظام اشتراكات كامل في البداية، إذ يكفي رابط دفع من بوابة تعمل في بلدك، أو فاتورة شهرية يدوية لأول عملائك.
اربط السعر بشيء يكبر مع قيمة العميل، مثل عدد المستخدمين أو الفروع أو حجم الاستخدام. وابدأ بسعر تستطيع الدفاع عنه بقيمة ما يوفره المنتج، فالسعر المنخفض بدافع الخوف قد لا يغطي تكلفة خدمتك ودعم عملائك. واحسب أيضًا تكلفة اكتساب العميل مبكرًا، لأن الاشتراك الشهري يسترد هذه التكلفة على عدة أشهر.
قبل أول فاتورة، اسأل محاسبك عن التزاماتك الضريبية في بلد عملك. في السعودية مثلًا تطبق هيئة الزكاة والضريبة والجمارك الفوترة الإلكترونية على مراحل بحسب صفحتها الرسمية في نوفمبر 2026، وهذا تنبيه وليس استشارة ضريبية.
الرقم الذي تتابعه بعد أول عميل
راقب عدد من بقوا يستخدمون المنتج بعد شهر، فالتسجيلات وحدها لا تخبرك بالكثير. مثال افتراضي: إذا سجل عشرة عملاء يدفعون، وبقي سبعة نشطين بعد شهر، فتحدث مع الثلاثة الذين توقفوا، واسأل عما كانوا يتوقعونه. أما إذا كان الناس يسجلون ويختفون، فسيزيد الإعلان عدد من يختفون، لذلك أصلح المنتج أولًا.
أسئلة شائعة
هل أحتاج إلى شريك تقني من البداية؟ لا تحتاج إليه في أول مرحلتين، فهما محادثات وصفحة واحدة. يصبح القرار مهمًا مع النسخة الأولى، وعندها تحتاج إلى من يفهم عزل البيانات والدفع.
ماذا لو توقفت الفكرة في المرحلة الأولى؟ تكون قد خسرت أسابيع من المحادثات بدل أشهر من البرمجة. راجع ما سمعته، فقد تجد فيه مشكلة أخرى تستحق الاختبار.
الخطوة التالية
اكتب هذا الأسبوع قائمة بخمسة عشر شخصًا من الفئة المستهدفة، وحدد علامة التوقف الخاصة بك كتابة، ثم ابدأ أول خمس محادثات. وعندما تمر الفكرة بالمراحل الأولى وتحتاج إلى من يبني النسخة الأولى، فتعرف على خدمة برمجة منتجات SaaS في بلانكيت.