منصات ويب ومنصات SaaS، مبنية لتستمر في العمل بعد الإطلاق.
نصمم ونبني ونشغّل منصات الويب ومنتجات SaaS للشركات والمؤسسين: حسابات وأدوار، وبيانات منفصلة لكل عميل، وفوترة، وشاشات تصمد أمام الاستخدام اليومي.
كيف تُبنى منصة تخدم عملاء متعددين
بيانات العملاء
أمان على مستوى الصفوف في Postgres مربوط بحساب كل عميل. وإذا احتاج عميل كبير لاحقًا إلى قاعدة بيانات خاصة به، فالانتقال لا يتطلب إعادة كتابة التطبيق.
تسجيل الدخول وSSO
جلسات قصيرة العمر يمكن إلغاؤها، وتسجيل دخول بالبريد الإلكتروني أو الحسابات الاجتماعية، ومفاتيح المرور، وSAML لعملاء الشركات، والتنقل بين المنظمات.
الفوترة
أحداث مزود الدفع تُسجل مرة واحدة وتُطابق. حدود الباقات وتغيير عدد المستخدمين ومتابعة الدفعات الفاشلة والفواتير يتولاها النظام، لا العمل اليدوي.
الأدوار وسجل التدقيق
أدوار مثل المالك والمسؤول والعضو والمدقق، إضافة إلى سجل غير قابل للتعديل يوضح من غيّر ماذا، ومتى، ومن أين.
أربع مشكلات شائعة نصمم لتجنبها.
معظم المنصات لا تتعثر لقلة المستخدمين. تتعثر لأن الاختصارات المبكرة تجعل أول طلب جاد من عميل مكلفًا في دعمه.
موقفنا
لا نكتب كودًا مؤقتًا يُرمى لاحقًا. الأساس مقسم إلى وحدات، وتشغيله رخيص في البداية، ومنظم بحيث يعني النمو زيادة في السعة، لا إعادة كتابة.
قواعد العمل مخلوطة بالشاشات
تتوزع القواعد بين وحدات التحكم (controllers) وكود الواجهة لتسريع الإطلاق. ثم يتحول أول طلب لتسعير مخصص أو علامة تجارية خاصة بالعميل أو تكامل إلى إعادة كتابة.
حدود واضحة بين الوحدات من البداية. طرق الدفع الجديدة أو الصلاحيات أو قواعد العملاء تُضاف دون المساس بالنواة.
الثقة العمياء بأحداث الدفع
أحداث مزود الدفع تصل متأخرة، أو بغير ترتيب، أو مرتين. ومن دون سجل لما تمت تسويته، يُمنع العملاء من الدخول أو يحتفظون بخصائص مدفوعة مجانًا.
كل حدث يُتحقق منه ويُسجل مرة واحدة ويُطابق، فيتطابق ما يستطيع العميل استخدامه مع ما يدفعه فعلًا.
التصفية يدويًا في كل استعلام
الاعتماد على أن يتذكر المطورون كتابة WHERE tenant_id = x في كل استعلام يعني أن سطرًا واحدًا منسيًا قد يكشف بيانات عميل آخر.
الأمان على مستوى الصفوف في Postgres يطبق التصفية على كل استعلام، فلا يعتمد الفصل على تذكّر أحد.
خدمات مصغرة قبل الحاجة إليها
منتج ناشئ موزع على خدمات وعناقيد كثيرة يعني صيانة أكثر، وتتبعًا أصعب للأخطاء، وتغييرات أبطأ.
تطبيق واحد منظم جيدًا بوحدات داخلية واضحة. يبقى النشر بسيطًا، ويمكن فصل أي وحدة لاحقًا إذا تطلب الحمل الفعلي ذلك.
الأساس الذي تقوم عليه كل منصة نبنيها.
لا نبدأ من مجلد فارغ. خصائصك تُبنى فوق أساس جاهز لدينا: تسجيل الدخول والحسابات والأدوار والفوترة والتدقيق. ومنتجاتنا، ORCAD وClivio، تعمل على أساس من النوع نفسه.
الحسابات والنطاقات المخصصة
إعداد ذاتي للمنظمة، ونطاقات فرعية مخصصة (مثل acme.yourproduct.com)، وشهادات SSL تلقائية، وإعدادات منفصلة لكل عميل.
- إعداد النطاقات عبر Cloudflare
- دعوة أعضاء الفريق ذاتيًا
تسجيل الدخول وSSO
تسجيل الدخول بالبريد الإلكتروني أو بدون كلمة مرور، ومفاتيح المرور (passkeys)، والدخول عبر الحسابات الاجتماعية، إضافة إلى SAML وOIDC لعملاء الشركات الذين يستخدمون Okta أو Microsoft Entra.
- إنشاء حسابات المستخدمين تلقائيًا
- تحقق ثنائي بمفاتيح المرور أو رموز التطبيق
الفوترة والباقات
باقات اشتراك، وتسعير حسب عدد المستخدمين أو حسب الاستخدام، ومعالجة الضرائب، وتغيير الباقة في منتصف الدورة، وبوابة يدير منها العملاء فواتيرهم بأنفسهم.
- Stripe أو Paddle أو بوابة دفع محلية
- حدود الباقات مرتبطة بالخصائص
الأدوار وسجل التدقيق
أدوار وصلاحيات على مستوى كل سجل، مع سجل غير قابل للتعديل يضاف إليه فقط، لعمليات تسجيل الدخول والتغييرات والتصدير.
- سجلات تساعد في التدقيق الأمني
- سجل قابل للبحث والتصدير
المهام الخلفية وWebhooks
مهام في طوابير للتقارير وملفات PDF والاستيراد الجماعي والإشعارات، إضافة إلى Webhooks صادرة لعملائك مع إعادة محاولة تلقائية.
- طوابير مهام تعتمد على Redis
- سجل تسليم Webhooks للعملاء
المراقبة
تتبع الأخطاء وتتبع الطلبات وعرض الاستخدام لكل عميل، مع تنبيهات تصلنا قبل أن يضطر مستخدموك إلى الإبلاغ عن مشكلة.
- Sentry وOpenTelemetry
- تتبع الاستعلامات البطيئة
من نموذج البيانات إلى منصة تعمل، في دورات مدتها أسبوعان.
النطاق ونموذج البيانات
الحسابات والبنية التحتية
دورات الخصائص
الأمان والأداء
الإطلاق والرعاية المستمرة
أدوات مجربة وشائعة. لا شيء اخترناه لأنه جديد.
نختار أدوات يسهل توظيف مهندسين لها، وموثقة جيدًا، ومستقرة تحت الضغط، حتى لا تكون المنصة مرتبطة بنا.
الواجهة الأمامية
واجهات بأنواع محددة لسير عمل يومي مزدحم، وتحميل سريع للصفحات، وتخطيطات بالعربية والإنجليزية.
واجهات API ومنطق العمل
وحدات واضحة بواجهات API موثقة، والتحقق من المدخلات عند كل نقطة دخول.
البيانات والتخزين المؤقت
قاعدة بيانات معاملات بقواعد وصول لكل عميل، وتخزين مؤقت، وتخزين ملفات مشفّر.
البنية التحتية
بيئات قابلة للتكرار، وتراجع بسيط، وبنية تحتية موصوفة بالكود، وكلها في حسابك السحابي.
ما تسأل عنه الشركات والمؤسسون قبل بناء منصة.
إجابات مباشرة عن المدد الزمنية وتغييرات النطاق والمراجعات الأمنية والعمل مع فريقك.
كم يستغرق الإصدار الأول؟
نتفق على ما يدخل في الإصدار الأول، ثم نقدّر المدة من هذه القائمة. يسير العمل في دورات مدتها أسبوعان، تنتهي كل منها بنسخة تعمل على بيئة الاختبار (staging)، ويذهب معظم الوقت إلى سير العمل الأساسي لديك، لا إلى الإعداد.
ماذا يحدث إذا تغير النطاق أثناء البناء؟
هذا يحدث عادةً. حين يتضح أن شيئًا جديدًا مهم، نستبدل به خاصية بحجم مماثل من الخطة، بدلًا من مد المدة أو الميزانية بصمت. وتتخذ هذا القرار معنا في نهاية كل دورة.
هل يمكنكم المساعدة في SOC 2 أو في مراجعة أمنية يطلبها عميل؟
نبني ونحن نضع التدقيق في الحسبان: تشفير البيانات المخزنة، وسجلات لتسجيل الدخول والتغييرات، وفصل بيانات العملاء داخل قاعدة البيانات، وتنبيهات بثغرات الاعتماديات. نساعدك في الاستعداد والرد على المراجعين، أما الحصول على الشهادة نفسها فمسؤوليتك.
هل يمكن لمهندسينا العمل معكم أثناء البناء؟
نعم. كثيرًا ما نعمل إلى جانب مدير تقني (CTO) أو مهندسين داخليين: مراجعات كود مشتركة، ومتابعات منتظمة، وعمل ثنائي، حتى يعرف فريقك الكود جيدًا عند الإطلاق.
لديك منصة أو منتج SaaS تريد بناءه؟
احجز مكالمة لتحديد النطاق مع مهندس ذي خبرة. نراجع خطتك، ونشير إلى المخاطر التقنية مبكرًا، ونقترح طريقة محددة لبنائها.
ما نغطيه في مكالمة تحديد النطاق:
- فصل بيانات العملاء: هل يحتاج عملاؤك أو الجهات الرقابية قواعد بيانات منفصلة، أم يكفي الفصل على مستوى الصفوف.
- نموذج الفوترة: تسعير حسب عدد المستخدمين أو حسب الاستخدام، والترقية والتخفيض، وأي مزود دفع يناسب سوقك.
- الإصدار الأول: ما يجب أن يكون في الإصدار الأول وما يمكن تأجيله، حتى تطلق في موعد واقعي.