تطوير منتجات SaaS بـ Next.js

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

نحن نبني هذه المنتجات، ونبدأ بهذه الثلاثة.

فصل المستأجرين، محسومًا قبل أول شاشة

هناك ثلاثة نماذج، والصحيح منها يتوقّف على عملائك لا على الموضة.

النموذج المشترك صحيح في معظم الأحيان، وخطره الحقيقي الوحيد استعلامٌ ينسى مرشّح المستأجر. وذلك ليس مشكلة انضباط تُحلّ بمراجعة الشيفرة - بل تُحلّ بأمن على مستوى الصفّ في قاعدة البيانات، فيُعيد المرشّح الغائب لا شيء بدل أن يُعيد بيانات غيرك.

التفويض عند البيانات لا عند المسار

الوسيط الذي يقرّر من يرى صفحةً بوّابة، والبوّابات مفيدة. لكنها ليست تفويضًا. فالـ Server Actions ومعالِجات المسارات تُستدعى مباشرة، وفحصٌ يعيش في الوسيط وحده فحصٌ لا تملكه نقطة النهاية.

كل استعلام يحمل المستأجر والفاعل. وكل تعديل يشتقّ الإذن من الجلسة من جديد بدل الوثوق بوسيط. والمنطق هو نفسه في Server Actions والأخطاء الثلاثة المتكرّرة، وفي منتج متعدّد المستأجرين لا يكون الفشل خللًا، بل عميلًا يقرأ بيانات عميل آخر.

فوترة تصمد أمام التدقيق

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

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

والتناسب والفترات التجريبية وتغيّر المقاعد والمدفوعات الفاشلة، كلٌّ منها حالة على الواجهة أن تعبّر عنها. وما يزال يحقّ لحسابٍ متأخّر فعله قرارُ منتج، ونحن نسأل عنه بدل اختراعه.

مشكلة لوحة التحكّم

لوحات SaaS هي الموضع الذي تبطؤ عنده تطبيقات App Router. والغريزة use client في الأعلى لأن هناك رسومًا ومرشّحات، فتذهب شجرة اللوحة كاملةً إلى المتصفّح.

الجداول والترويسات والتنقّل وجلب البيانات تبقى على الخادم. أما الرسم والمرشّح ومنتقي التاريخ فجزر عميل. وحالة الرابط تحمل المرشّحات، فتصير الرؤية المُرشَّحة قابلة للمشاركة ويعمل زرّ الرجوع كما ينبغي. ولا تنتظر أي صفحة أبطأ عناصرها - بل يتدفّق كلٌّ خلف حدّه، وهذا هو مغزى أن loading.tsx ليس مؤشّر تحميل.

ما لا نفعله

لا نبدأ من قالب SaaS جاهز. فهي تُرمّز قرارات فصل ومصادقة وفوترة اتُّخذت لمنتج آخر، وفكّها لاحقًا يكلّف أكثر من الأسبوعين اللذين وفّرتهما.

ولا نبني لوحة الإدارة أولًا. فهي الجزء الذي يستمتع المؤسّسون بتحديده أكثر من غيره، والجزء الذي لا يراه العملاء أبدًا.

كيف يسير العمل

الأسبوع الأول قرار لا بناء: أي نموذج لتعدد المستأجرين، وأي عزل سيلزمكم إثباته، وعمّ ستسأل المراجعة الأمنية لأكبر عميل محتمل لديكم.

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

ثم المراحل، ينتهي كلٌّ منها منشورًا، واختبارات العزل مكتوبةً إلى جانب المزايا.

ما الذي تحصلون عليه

نموذج تعدد المستأجرين والصلاحيات محسومًا كتابةً قبل أول شاشة، ثم المنتج مبنيًّا عليه. ومجموعة الاختبارات هنا أثقل وزنًا من المعتاد، لأن الاختبارات التي تهم هي التي تؤكد فشلًا: طلبٌ يحمل جلسة مستأجر يجب ألا يبلغ صفَّ مستأجر آخر.

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