بناء SaaS باستخدام Lovable — دليل عملي شامل من الفكرة إلى الإطلاق
خارطة تطبيقية لبناء منتج SaaS كامل على Lovable: الهبوط، المصادقة، قاعدة البيانات، الأدوار، الدفع، Webhooks، لوحة الإدارة، البريد، التحليلات، RLS، الاختبارات، ثمّ النشر والمتابعة.
١) صفحة الهبوط: أوّل حكم يصدره المستخدم
صفحة الهبوط ليست ديكورًا. مهمّتها الوحيدة: أن يصل الزائر خلال 10 ثوانٍ إلى قرار «هذا يخصّني، جرّبته». اطلب من Lovable هيروًا تحريريًّا (عنوان قصير، جملة توضيح، زرّ CTA واحد رئيسي، شريط ثقة). أضف قسمًا واحدًا لكلّ سؤال يخطر ببال الزائر: ماذا يفعل؟ لمن؟ كيف يشتغل؟ كم يكلّف؟ من يستخدمه؟ ثمّ FAQ. تجنّب الحشو: صفحة قصيرة تركّز على قرار «ابدأ مجاناً» أفضل من صفحة طويلة بلا نيّة.
برومبت مقترح: «أنشئ صفحة هبوط لمنتج SaaS اسمه X، جمهوره Y، بمشكلة Z. أربعة أقسام: هيرو، ثلاث ميزات، FAQ، CTA أخير. dir=rtl، خط IBM Plex Sans Arabic، بدون تدرّجات لونية عريضة، مع زرّ رئيسي واحد يقود إلى /auth.»
٢) التسجيل والمصادقة
فعّل Lovable Cloud بنقرة. Lovable يوفّر بريد+كلمة مرور، وGoogle، وApple. للسوق العربي ابدأ بـ«بريد + Google» فقط، لا تفرط في الخيارات. أنشئ صفحتين واضحتين: /auth للدخول والتسجيل، و/auth/reset لاستعادة كلمة المرور. فعّل «تحقّق البريد الإلكتروني» قبل الوصول إلى المنتج، وأضف صفحة /reset-password تقرأ الرابط من الـURL وتحدّث كلمة المرور. لا تحفظ الجلسة يدويًّا في localStorage — استخدم عميل Supabase الافتراضي.
٣) قاعدة البيانات: صمّم قبل أن تكتب
ارسم الجداول قبل فتح المحرّر. الحدّ الأدنى لأيّ SaaS:
- profiles: يمتد من auth.users (id UUID، display_name، avatar، locale، created_at). أنشئه بـtrigger عند إنشاء المستخدم. - subscriptions: user_id، plan، status، current_period_end، provider_customer_id. - جدول واحد أو اثنان للميزة الأساسية (مثلًا invoices، أو projects، أو contacts).
كلّ جدول عامّ لازم يحصل على GRANT صحيح ثمّ ENABLE ROW LEVEL SECURITY ثمّ سياسات دقيقة. لا تعتمد على «كلّ الصفوف تُقرأ»؛ اجعل كل سياسة مقيّدة بـauth.uid().
٤) الميزة الأساسية: افعل شيئًا واحدًا بشكل ممتاز
المستخدم لا يدفع مقابل «منصّة» — يدفع مقابل عمل واحد يتمّ بسرعة وبدقّة. اختر ميزة واحدة (توليد فاتورة، إدارة عملاء محتملين، جدولة مهام، تحليل بيانات) وابنها من طرف إلى طرف: نموذج إدخال، معالجة، عرض النتيجة، تصدير. لا تضف الميزة الثانية قبل أن تعمل الأولى مع خمسة مستخدمين حقيقيين.
قاعدة الشحن: كلّ إضافة جديدة تكلّفك خمس مشاكل مستقبلية (اختبار، توثيق، دعم، صيانة، هجرة بيانات). اجعل الإضافة تستحق.
٥) الأدوار والصلاحيات
لا تخزّن الدور داخل جدول profiles — هذا يفتح باب رفع الصلاحيات (Privilege Escalation). أنشئ:
- ENUM اسمه app_role: 'admin' | 'moderator' | 'user'. - جدول user_roles (user_id، role) مع UNIQUE(user_id, role) وRLS. - دالّة SECURITY DEFINER اسمها has_role(_user_id، _role) تُستخدم داخل سياسات RLS بدل الاستعلام المباشر لتفادي التكرار (Recursion).
بعدها استخدم has_role(auth.uid(), 'admin') داخل السياسات، وفي الواجهة أخفِ الأزرار الحسّاسة، لكن اعتمد دائمًا على التحقّق من جهة الخادم لا الواجهة فقط.
٦) الدفع والاشتراكات
على Lovable لديك خياران مدمجان: Paddle (تاجر مسجَّل، يهتمّ بالضرائب عالميًّا) وStripe (مرونة أكبر، خصوصًا في أميركا وأوروبا). للمنتجات الرقمية للسوق العالمي ابدأ بـPaddle. للسوق الخليجي مع اشتراكات ثابتة، Stripe مناسب أيضًا. أنشئ خطّتين لا أكثر في البداية (Free/Pro، أو Starter/Business). كلّ خطّة لها product_id وprice_id في مزوّد الدفع، وسجّلها في جدول plans داخل قاعدتك للربط.
قاعدة مهمّة: لا تُظهر ميزة «قيد التطوير» في جدول الأسعار. اعرض فقط ما يعمل الآن.
٧) Webhooks: نقطة تلاقي المنتج مع المدفوعات
Webhook هو الرسالة التي يرسلها Stripe/Paddle حين يتمّ الدفع أو يفشل. أنشئ مسارًا عامًّا مثل /api/public/webhooks/stripe يتحقّق أوّلاً من التوقيع (Signature) قبل قبول أيّ بيانات. الفشل في التحقّق = 401 فورًا. بعد التحقّق، حدّث جدول subscriptions: الحالة الجديدة (active/past_due/canceled)، تاريخ انتهاء الفترة، ومعرّف العميل.
قاعدة الأمان: Webhook قد يصل مرّتين لنفس الحدث (Retry). صمّم المعالجة لتكون Idempotent: تحقّق من event_id قبل الكتابة، ولا تكرّر الفعل.
٨) لوحة الإدارة
كلّ SaaS يحتاج لوحة يستخدمها صاحب المنتج (أنت): مستخدمون، اشتراكات، سجلّ الأخطاء، طلبات الدعم. أنشئ مسارًا محميًّا /admin مقيّدًا عبر has_role(auth.uid(), 'admin'). أضف جدولًا واحدًا لكلّ مورد، مع بحث وترقيم صفحات. لا تحتاج جماليات مبهرة — تحتاج سرعة قراءة واتخاذ قرار. أضف زرّ «تسجيل الدخول بهويّة المستخدم» (Impersonation) فقط بعد أن تنضج المنتج، ومع سجلّ (audit log) لكلّ عملية.
٩) البريد والإشعارات
عند التسجيل، عند الدفع، عند فشل الدفع، عند إتمام مهمّة، عند دعوة عضو للفريق — كلّها لحظات تحتاج بريدًا. استخدم Lovable Email من نطاقك المخصّص لبريد بهويّة موثوقة (لا @gmail، لا رسائل من نطاق مزوّد الاستضافة). صمّم قوالب موحّدة: ترويسة، محتوى، زرّ CTA، تذييل. اجعل النبرة عربية بشرية، لا حرفيّة مترجمة. أضف رابط «إلغاء الاشتراك» في كلّ بريد تسويقي (مطلوب قانونيًّا).
١٠) التحليلات
بدون تحليلات، أنت تخمّن. أضف على الأقلّ:
- GA4 أو Plausible لقياس الزيارات والصفحات. - Analytics داخلي يسجّل الأحداث المهمّة: signup_completed، subscription_started، feature_used، churn_reason. جدول واحد events(user_id, name, props jsonb, created_at). - لوحة KPIs بسيطة داخل /admin: تسجيلات اليوم، اشتراكات نشطة، MRR تقديري، معدّل إلغاء الاشتراك.
راقب مؤشّرًا واحدًا كلّ أسبوع، لا عشرة معًا.
١١) RLS: الحصن الأخير
RLS ليست خيارًا رفاهيًّا — بدونها أيّ مستخدم يقرأ بيانات الآخرين. القاعدة الذهبية:
- SELECT: USING (auth.uid() = user_id). - INSERT: WITH CHECK (auth.uid() = user_id). - UPDATE/DELETE: USING + WITH CHECK كلاهما. - للجداول التي فيها أعضاء فريق، استخدم جدول memberships(team_id, user_id, role) ودالّة SECURITY DEFINER تعيد صلاحيّة العضو داخل الفريق، ثمّ استدعها في السياسات.
اختبار سريع: سجّل دخول بحسابين مختلفين وحاول أن تقرأ بيانات الآخر من devtools. إن نجحت، سياستك مكسورة.
١٢) الاختبارات
لا تحتاج تغطية 100%. تحتاج شبكة أمان لثلاث مسارات: التسجيل، الدفع، الميزة الأساسية. اطلب من Lovable إضافة اختبارات Playwright تغطّي:
- زائر → صفحة الهبوط → /auth → تسجيل ناجح → لوحة التحكّم. - مستخدم → صفحة الاشتراك → إتمام دفع تجريبي → عودة إلى /billing → ظهور «الاشتراك نشط». - المستخدم يستطيع القيام بالميزة الأساسية من طرف إلى طرف.
شغّل هذه المسارات قبل كلّ نشر. أيّ فشل = أوقف الإطلاق.
١٣) النشر والمتابعة
اربط دومينك من إعدادات المشروع، تأكّد من HTTPS التلقائي، حدّث canonical في كلّ الصفحات، ثمّ اضغط Publish. في الأسبوع الأوّل بعد الإطلاق:
- راقب سجلّ الأخطاء يوميًّا (Errors → Server function logs). - تابع أوّل ٢٠ مستخدمًا واحدًا بواحد: راسلهم، اسألهم عن الاحتكاك. - سجّل كلّ طلب دعم في جدول واحد. تكرار الطلب مرّتين = ميزة أو إصلاح مطلوب. - حدّث الأسعار بعد ٣٠ يومًا فقط، بناءً على بيانات، لا انطباعات.
الخلاصة: SaaS ناجح على Lovable ليس مسألة كود — بل انضباط منتج. صفحة تُقنع، مصادقة موثوقة، ميزة واحدة تُنجز عملًا حقيقيًّا، RLS محكمة، مدفوعات مُختبَرة، وحلقة تعلّم أسبوعية. ابدأ صغيرًا، اشحن مبكرًا، وحسّن بناءً على بيانات.
للتعمّق: راجع Lovable Cloud، والأسعار، ودليل بناء أوّل مشروع.
هل كان هذا المحتوى مفيداً؟
استلم أحدث الأدلّة والبرومبتات كل أسبوع
خلاصة عربية أسبوعية عن Lovable وVibe Coding — بلا سبام، إلغاء متى شئت.