GrowFast احتاج إدارة مسرّعة — برامج، فعاليات، عروض وظائف، ومدفوعات — بدون تجميع خمس أدوات مختلفة. أرادوا منصة واحدة تسجّل فيها الشركات الناشئة بالبرامج، يسجّل المشاركون بالفعاليات، يتقدم المرشحون للوظائف، وكل شيء متصل ببنية دفع حقيقية. Stripe للمعاملات الدولية. Alipay للسوق الصيني.
اثنا عشر شهرًا، أربعة أشخاص، وبناء من الصفر لاحقًا، كانت المنصة تعمل. هذا أطول وأعقد مشروع لنا حتى الآن.
لماذا لم يشتروا
أول سؤال طرحناه — كما نفعل دائمًا — كان هل يجب أن يبنوا أصلًا. أدوات إدارة المسرّعات موجودة. Eventbrite يدير الفعاليات. لوحات الوظائف سلعة.
المشكلة كانت الروابط بين هذه الأشياء. شركة ناشئة مسجلة في برنامج يجب أن تحصل تلقائيًا على وصول لفعاليات البرنامج. مشارك في فعالية هو أيضًا عضو برنامج يجب أن يرى ملفًا موحدًا. طلبات التوظيف يجب أن تكون مرئية للمرشدين. مطابقة المدفوعات عبر Stripe وAlipay تحتاج أن تصل للوحة واحدة، وليس اثنتين.
لا يوجد تركيبة من الأدوات الجاهزة تستطيع تقديم هذا بدون طبقة تكامل ستكون بحد ذاتها مشروع برمجي. فبنينا كل شيء.
المعمارية
Laravel كان العمود الفقري — يتولى البرامج، الفعاليات، الوظائف، المستخدمين، الأدوار، المدفوعات، الإشعارات، ولوحة الإدارة.
طبقة الدفع كانت القطعة الأهم معماريًا. Stripe وAlipay لديهما نماذج تكامل مختلفة جذريًا. بنينا خدمة دفع موحدة تخفي كلاهما وراء واجهة واحدة.
تكرار الأمان في webhooks كان حرجًا. كلا البوابتين يمكن أن ترسلا نفس الحدث عدة مرات. نفذنا إزالة التكرار على مستوى معالج webhook باستخدام هاشينغ مرجع المعاملة.
أصعب المشاكل
مطابقة المدفوعات عبر البوابات
تسويات Stripe تصل كدفعات، وليس معاملات فردية. Alipay له دورة تسوية خاصة مع تحويل عملات. بنينا محرك مطابقة يقارن سجلات المنصة بتقارير البوابات. مهام مطابقة ليلية اكتشفت ثلاث حالات عدم تطابق في الشهر الأول بعد الإطلاق.
التحكم بالوصول عبر وحدات مترابطة
المسرّعة لديها أنواع مستخدمين كثيرة: مديرو برامج، مرشدون، مؤسسو شركات ناشئة، منظمو فعاليات، ناشرو وظائف، متقدمون، مشاركون، ومسؤولون. نفذنا RBAC دقيق بـ Policies Laravel مع أذونات مقيدة بكل وحدة.
إيصال البريد الإلكتروني على نطاق واسع
نفذنا مصادقة النطاق (SPF, DKIM, DMARC)، قوائم انتظار مع منطق إعادة المحاولة، وإدارة الارتدادات. قوالب البريد كائنات قابلة للتعديل في الإدارة.
ما سلّمناه
تسجيل ومتابعة الشركات الناشئة: برامج مع نماذج تقديم وسير عمل مراجعة وتتبع معالم.
الفعاليات: إنشاء، تذاكر، تسجيل، دفع، وتتبع حضور. الفعاليات يمكن ربطها بالبرامج.
الوظائف: نشر عروض، طلبات توظيف، إدارة مرشحين، وتكامل مع منظومة البرامج.
المدفوعات: Stripe وAlipay مع webhooks موثقة، إيصالات آلية، إدارة استرداد، ومطابقة ليلية.
لوحة الإدارة: لوحات تشغيلية، إدارة أدوار، تحليلات وتصدير CSV.
اثنا عشر شهرًا: كيف هيكلناه
الشهر 1: اكتشاف. مقابلات أصحاب المصلحة. لم نكتب كودًا — كتبنا وثائق. مرحلة التحديد في مشروع بهذا الحجم هي الفرق بين بناء محكوم وميزانية خارجة عن السيطرة.
الشهران 2-3: النطاق والعقود. نمذجة المجال، عقود API، تدفقات UX، وتصميم مسارات الدفع.
الأشهر 4-10: البناء. الوحدات الأساسية أولًا، ثم المدفوعات، ثم الفعاليات والوظائف، ثم الإشعارات والتقارير. عروض كل أسبوعين طوال الفترة.
الشهر 11: التقوية. بنية الإنتاج، اختبارات الحمل، تدقيق أمني.
الشهر 12: الإطلاق والتسليم. دفاتر التشغيل، تدريب الفريق.
ما تعلمناه
صمم تدفقات الدفع مبكرًا. صممنا معمارية الدفع في الشهر 2، وليس الشهر 6.
استخدم واجهات برمجة مُصدَّرة وDTOs لتكاملات مستقرة. عندما يغير Stripe أو Alipay واجهته، نحدّث ملف ربط واحد، وليس منطق العمل.
المراقبة ودفاتر التشغيل تقلل العبء التشغيلي. عند الإطلاق، كان لدى فريق العمليات دفتر تشغيل لكل تنبيه.
أبقِ الإدارة بسيطة؛ حسّن حيث يقضي الموظفون وقتهم. بالغنا في هندسة واجهة الإدارة في البداية. في النصف الثاني، راقبنا المهام الأكثر تكرارًا وحسّنا تلك التدفقات تحديدًا.
الاختبارات الآلية حول الفوترة تمنع الانحدار. كود الدفع هو الأخطر عند كسره.
النتيجة
GrowFast أطلقت منصة موحدة تغطي برامج الشركات الناشئة، الفعاليات، الوظائف، والمدفوعات المتكاملة عبر Stripe وAlipay.
لكل التفاصيل، اقرأ دراسة حالة GrowFast الكاملة.
تخططون لشيء بهذا الحجم؟
بناء 12 شهرًا بأربعة أشخاص استثمار جدي. إذا كنتم تفكرون بمنصة بهذا النطاق، ابدأوا بـ موجز متين، افهموا ما يحرك الجداول الزمنية، واعرفوا ماذا تسألون قبل التوقيع.
لديكم مشروع منصة في ذهنكم؟ لنحدد نطاقه معًا →