بديل Lovable (مجاني ومفتوح المصدر)

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

إجابة سريعة: هل ينبغي أن تترك Lovable؟

• ابق مع Lovable عندما تكون قيمة التكرار البصري وقاعدة البيانات/المصادقة/التخزين المُدارة وقصر وقت الإعداد هي الأهم.
• استخدم حزمة قائمة على Eigent عندما تكون السيطرة على المصدر والنموذج والخلفية والنشر أهم من سهولة النقرة الواحدة.
• استخدم OpenHands أو Cline أو Aider عندما تريد وكيلاً مفتوحاً مركزاً للبرمجة بدلاً من مساحة عمل عامة متعددة الوكلاء.
• استخدم منشئاً مستضافاً آخر مثل Replit أو Bolt أو v0 عندما تكون السرعة هي الأولوية، مع إدراك أن كل واحد منها يحتفظ بحدود منصة.

أفضل وقت للترحيل هو بعد التحقق من المنتج وقبل أن تصبح الزيارات والبيانات والمصادقة والتخزين والأتمتة صعبة الفك.

لماذا يحظى Lovable بشعبية؟

يجمع Lovable الأجزاء التي تبطئ عادةً المنتج الأولي: توليد الشيفرة بالوصف، والتكرار البصري، وتجهيز الخلفية، والمصادقة، والتخزين، والدوال، والاستضافة. بُني Lovable Cloud على أساس Supabase مفتوح المصدر، ويوفر مناطق في الأمريكتين وأوروبا وآسيا والمحيط الهادئ (وثائق Lovable Cloud).

اجتذبت هذه السهولة استخداماً كبيراً. قالت Lovable لـ TechCrunch في يونيو 2026 إنها تجاوزت معدل إيرادات سنوي قدره 500 مليون دولار، وأنها تنشئ مليون مشروع جديد كل أسبوع؛ وكلا الرقمين مُبلّغ عنه من الشركة نفسها (TechCrunch). وجمعت جولة تمويل في ديسمبر 2025 مبلغ 330 مليون دولار بتقييم 6.6 مليار دولار (Bloomberg).

تسعير Lovable ونموذج الرصيد الموحّد

سردت مراجعة عملية في يوليو 2026 خطة Free بخمس مطالبات يومياً وبحد أقصى 30 شهرياً، وخطة Pro بسعر 25 دولاراً شهرياً مع 100 رسالة شهرية وخمس رسائل يومية، وخطة Business بسعر 50 دولاراً شهرياً مع الأساس نفسه البالغ 100 رسالة وميزات للفريق (مراجعة TechRadar). ينبغي التحقق من الحصص الحية مرة أخرى قبل الشراء.

في يونيو 2026 وحّدت Lovable فوترة البناء وCloud وذكاء التطبيقات المنشورة في رصيد ائتماني واحد. وقالت الشركة إن أسعار الخطط ومعدلات الاستهلاك لم تتغير، وإن المشتركين احتفظوا بخمسة أرصدة بناء يومية مجانية (منشور فوترة Lovable). وهذا يجعل تمييزاً واحداً ضرورياً: أرصدة Lovable ليست مطالبات فقط. فقد تستمر الخلفية وذكاء التطبيق المنشور في استهلاك الأرصدة بعد البناء الأولي.

وثّقت صفحة حالة Lovable أيضاً حادثة في مارس 2026 لم تظهر فيها الأرصدة المشتراة لعدة مستخدمين (حادثة حالة Lovable). كانت تلك حادثة تشغيلية محددة، وليست دليلاً على مشكلة منهجية في الفوترة.

ما الذي يتطلبه بديل Lovable مفتوح المصدر فعلياً؟

Eigent مساحة عمل متعددة الوكلاء بترخيص Apache-2.0 يمكنها تنسيق البحث والبرمجة وعمل المتصفح وأوامر الطرفية والاختبار والتحضير للنشر (مستودع Eigent). يمكن تشغيل التطبيق محلياً أو استضافته ذاتياً، ويستطيع المشغّل اختيار نموذج مستضاف أو محلي متوافق.

تبقى بقية الحزمة صريحة:

Product brief
   ↓
Eigent + coding agent
   ↓
Git repository and tests
   ↓
Chosen database / auth / storage
   ↓
Container and independent host

يحافظ هذا التصميم على قابلية نقل المستودع وقابلية استبدال طبقة البيانات. لكنه يطلب من الفريق اتخاذ قرارات يتولاها Lovable عادةً: الإطار والمخطط والمصادقة والنسخ الاحتياطي والمراقبة والتوسع والنشر.

Lovable مقابل حزمة قائمة على Eigent

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

ما الذي يفعله Lovable على نحو أفضل؟

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

تمثل قاعدة البيانات والمصادقة والتخزين والوقت الحقيقي والدوال والذكاء الاصطناعي المتكاملة في Lovable Cloud مزايا منتج فعلية (وثائق Lovable Cloud). إذا لم يكن فريقك قادراً على تشغيل هذه الطبقات، فقد تزيد الهجرة لمجرد تجنب الأرصدة التكلفة الكلية والمخاطر.

سير عمل عملي لبناء تطبيق مفتوح

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

1. حوّل المطالبة إلى معايير قبول

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

2. اختر حد البيانات

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

3. صمّم المخطط قبل الواجهة

أنشئ عمليات الترحيل والقيود وقواعد الصلاحية في Git. عامل المصادقة والتفويض كمتطلبين منفصلين؛ فشاشة تسجيل دخول عاملة ليست دليلاً على صحة الوصول على مستوى السجل.

4. ابنِ بزيادات قابلة للمراجعة

ولّد ميزة واحدة في كل مرة. شغّل اختبارات الوحدة والتكامل والمتصفح بعد كل خطوة. استخدم computer-use QA للتحقق من المسار المرئي، لكن احتفظ بالمراجعة البشرية للأمان وحكم المنتج.

5. غلّف بيئة التشغيل

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

6. انشر إلى بيئة اختبار أولاً

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

كيفية الترحيل من Lovable

1. زامن أو استنسخ مستودع Git. ضع وسم الإصدار الأخير الذي أدارته Lovable وأعد إنتاجه محلياً.
2. احصر خدمات Lovable Cloud. اربط كل جدول وموفر مصادقة ودالة وحاوية تخزين ومهمة مجدولة وسر واستدعاء AI منشور.
3. صدّر البيانات وتحقق منها. قارن أعداد السجلات والعلاقات والطوابع الزمنية وبيانات الملفات.
4. دوّر الأسرار. أعد إنشاء مفاتيح API وبيانات اعتماد OAuth بدلاً من نسخها إلى بيئة جديدة غير محكومة.
5. أعد بناء المصادقة بعناية. اختبر ربط الحسابات وإعادة تعيين كلمات المرور والتحقق من البريد الإلكتروني والجلسات وقواعد التفويض.
6. اختر الاستضافة وقابلية الملاحظة. أضف السجلات والمقاييس وتقارير الأخطاء والنسخ الاحتياطية ومسؤول الحوادث.
7. انقل DNS بعد تدريب. أبق النشر القديم متاحاً إلى أن ينجح النشر الجديد في اختبارات الدخان.

لا يوجد وعد مسؤول بترحيل قاعدة البيانات أو المصادقة أو التخزين تلقائياً. تحتاج كل واحدة من تلك الطبقات إلى خطة تصدير وتحويل مختبرة.

بدائل Lovable الأخرى

Replit

Replit هو البديل المتكامل الأقرب بين المنشئين السائدين لأنه يجمع IDE في المتصفح وAgent وبيئة التشغيل وقاعدة البيانات والنشر. وهو يستخدم أيضاً الاشتراكات وعمل الوكلاء القائم على الجهد والبنية المتكاملة، ولذلك فهو انتقال للراحة لا للملكية (شرح تسعير Replit).

OpenHands

يوفر OpenHands نواة وكيل برمجي بترخيص MIT مع مسارات نشر محلية وDocker (مستودع OpenHands). وهو قوي للفرق التقنية، لكنه لا يعيد إنتاج صقل Lovable البصري من المطالبة إلى التطبيق.

Cline وAider

Cline وكيل IDE/CLI بترخيص Apache-2.0 مع موافقات Plan/Act صريحة (مستودع Cline). وAider مبرمج زوجي طرفي بترخيص Apache-2.0 وتعديلات أصلية لـ Git (مستودع Aider). يفترض كلاهما أنك ستوفر بنية الخلفية والنشر.

المنشئون البصريون المستضافون

قد يكون Bolt وv0 وBubble وSoftr أفضل لاحتياجات واجهة المستخدم واللا-كود المختلفة. قيّم ملكية الشيفرة المولدة وقابلية نقل الخلفية وتصدير البيانات وتسعير بيئة التشغيل وكلفة المغادرة، لا جودة المطالبة الأولى وحدها.

لمقارنة أكثر تحديداً، راجع /blog/claude-design-vs-lovable.

متى ينبغي أن تبقى مع Lovable؟

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

تخرّج من النموذج الأولي إلى سير عمل مملوك

يكون Eigent أكثر فائدة بعد أن يثبت MVP من Lovable وجود الطلب ويصبح فريقك مستعداً لامتلاك خط بناء التطبيق. استخدمه لتنسيق إعادة بناء قابلة للفحص واختبر التطبيق باستخدام computer use، مع إبقاء اختيارات قاعدة البيانات والنشر صريحة. نزّل Eigent وابدأ بنسخة مرحلية مبنية من بيانات اصطناعية.