هل يمكن الربح من تطبيقات الذكاء الاصطناعي؟ ولماذا تفشل بعض مشاريع SaaS؟

حين يستطيع الجميع تقريبًا بناء تطبيق، لا تكمن الميزة في سرعة كتابة الكود وحدها، بل في فهم المشكلة والوصول إلى العملاء وإثبات القيمة.

من سؤال البناء إلى سؤال البيع

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

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

لماذا أصبح تطوير التطبيقات أسهل؟

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

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

ويعكس استطلاع Supabase عن حالة الشركات الناشئة لعام 2026 ملامح هذا الواقع؛ إذ جمع إجابات نحو 2,000 من بناة الشركات الناشئة، ووصف 61% من المشاركين أنفسهم بأنهم مؤسسون منفردون. لا تثبت هذه النسبة أن الذكاء الاصطناعي هو سبب هذا النمط، وهي تصف من اختاروا المشاركة لا كل الشركات الناشئة، لكنها تكشف شريحة واسعة من البناة يعملون بفرق صغيرة جدًا.

الأرقام تكشف الفجوة بين بناء التطبيق وبيعه

في الاستطلاع نفسه، اختار 32% من المشاركين اكتساب العملاء بوصفه التحدي التجاري الأكبر، وقال 56% إن أول عملائهم الدافعين جاؤوا عبر شبكاتهم الشخصية أو المهنية. أي إن كثيرين يرون أن العقبة في البيع لا في البناء. ويعتمد الاستطلاع على مشاركين اختاروا الإجابة بأنفسهم، فيُقرأ مؤشرًا على حال المشاركين لا مقياسًا للسوق كله.

وعلى جانب المشترين، أفاد تقرير McKinsey عن حالة الذكاء الاصطناعي لعام 2026 بأن 32% من المؤسسات المشاركة امتنعت عن شراء منتج برمجي أو ميزة واحدة على الأقل لأنها بنتها داخليًا بالبرمجة المدعومة بالذكاء الاصطناعي. وهذه النسبة تخص المؤسسات المشاركة لا جميع الشركات في العالم، وتشير إلى قرار واحد على الأقل بين الشراء والبناء، لا إلى تخلٍّ كامل عن البرمجيات الجاهزة.

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

لماذا قد ينجح التطبيق تقنيًا ويتعثر تجاريًا؟

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

1. مشكلة غير ملحّة

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

2. عميل غير محدد

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

3. كلفة انتقال غير محسوبة

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

4. توزيع ضعيف

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

5. استبقاء وهامش ربح ضعيفان

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

إذا كان البناء سهلًا، فأين الميزة التنافسية؟

حين يصبح الكود أقل ندرة، تنتقل الميزة إلى ما يصعب نسخه بسرعة. ومن مصادرها المحتملة:

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

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

مثال من السوق السعودية: إدارة طلبات الصيانة

مثال توضيحي فقط: السيناريو التالي افتراضي، وليس حالة شركة منشورة، والأرقام فيه أهداف للنقاش لا نتائج متحققة.

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

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

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

وقد تخضع بعض القطاعات لمتطلبات تنظيمية أو تعاقدية تخص البيانات وحفظها، فيلزم التحقق منها مع العميل قبل التشغيل.

قائمة من سبع خطوات لاختبار فكرة SaaS قبل الإنفاق على بنائها

هذه قائمة تحقق عملية، لا وعد بدخل خلال مدة محددة.

1. اختر شريحة ضيقة: قطاعًا ودورًا وحجم منشأة محددين.
2. أجرِ عشر مقابلات مع أشخاص يعيشون المشكلة فعلًا، واستمع أكثر مما تعرض.
3. حدد مدى تكرار المشكلة والحل البديل الذي يستخدمونه اليوم، ولو كان جدول بيانات.
4. قدّر كلفة المشكلة على أعمالهم بأرقامهم هم، لا بتقديراتك.
5. اصنع عرضًا تجريبيًا بسيطًا يركز على النتيجة لا على الخصائص.
6. اعرض تجربة مدفوعة محددة النطاق والمدة والسعر.
7. احكم على الاستخدام المتكرر الفعلي والاستعداد للتجديد، لا على عبارات الإعجاب.

وإن كانت الأدلة مشجعة لكن الإطلاق يتأجل مرة بعد أخرى، فمقالنا عن المشروع الناشئ الذي لا ينطلق أبدًا يتناول أسباب تأجيل المؤسسين لذلك الإطلاق التجريبي الأول.

خمسة أرقام أهم من عدد المستخدمين

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

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

ويتسق ذلك مع تحليل BCG بالتعاون مع Stripe وAWS في أكتوبر 2026، الذي يرى أن المنافسة المدفوعة بالذكاء الاصطناعي تضغط على الأسعار، وأن ربط السعر بالقيمة التي يدركها العميل صار أكثر أهمية. ويصف التقرير تحولًا من التسعير بحسب عدد المستخدمين إلى نماذج هجينة، وفي عينة Stripe من شركات SaaS ذات النمو المتسارع اعتمدت 57% منها تسعيرًا هجينًا يجمع الاشتراك مع عناصر مرتبطة بالاستخدام أو النتائج. وهذه النسبة تصف شركات سريعة النمو في عينة واحدة، لا جميع شركات SaaS. ويبقى الاشتراك نموذجًا قابلًا للاستمرار، لكنه يحتاج إلى قيمة قابلة للقياس تبرره.

رؤية نوى: ابدأ من النتيجة لا من التطبيق

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

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

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

اعتراضات وحدود الأدلة

ينبغي الفصل بين ما تقوله استطلاعات 2026 فعلًا وما نستنتجه منها. فتكوين المشاركين في استطلاع Supabase ومرحلة نضج مشاريعهم قد يفسران جزءًا من الأنماط المرصودة، ولا يصح تعميم نتائجه على السوق السعودية أو على كل الشركات الناشئة. ونتيجة McKinsey تخص قرارًا واحدًا على الأقل بين الشراء والبناء لدى المؤسسات المشاركة، لا تحولًا شاملًا. ونسبة التسعير الهجين لدى BCG تخص عينة محددة من الشركات ذات النمو المتسارع.

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

الخلاصة: سهولة البناء لا تعني سهولة الربح

يستطيع كل مؤسس تقريبًا أن يبني تطبيقًا أسرع من ذي قبل، لكن العميل لا يشتري الكود؛ بل يشتري نتيجة تستحق ما يدفعه.

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

المصادر

• State of Startups 2026، Supabase، 2026. استطلاع لنحو 2,000 من بناة الشركات الناشئة؛ عينة ذاتية الاختيار لا تمثل السوق كله.
• The state of AI، McKinsey & Company، 2026. استطلاع مؤسسي؛ النسب تخص المؤسسات المشاركة.
• SaaS Pricing Must Change in the Age of Agentic AI، BCG بالتعاون مع Stripe وAWS، أكتوبر 2026. نسبة التسعير الهجين تخص عينة Stripe من الشركات ذات النمو المتسارع.