البناء أم الشراء: هل تبني برمجيات مخصصة؟

اشترِ، أو اضبط، البرنامج الذي يتشابه فيه كل أصحاب الأعمال في مجالك، وابنِ البرنامج الذي يميّزك عنهم. فإذا كان في السوق منتج ناضج يلبي معظم سير عملك، فالشراء أسرع وأرخص في البداية وأقل مخاطرة. وابنِ حين يكون البرنامج جزءًا من تنافسك، أو حين لا يناسبك منتج إلا بحلول التفافية مؤلمة، أو حين تحتاج إلى امتلاك البيانات وخارطة الطريق.

ونادرًا ما يكون الاختيار كليًا. فمعظم المؤسسات ينتهي بها الأمر إلى مزيج، ولذلك فالسؤال المفيد ليس «نبني أم نشتري؟» بل «أي الأجزاء مكانه أين، وما الذي يدفعنا إلى نقل جزء منها لاحقًا؟»

ابدأ بالجوهري مقابل الشائع

البرنامج **الجوهري** هو ما يدعم سبب اختيار العملاء لك، أو عملية فريدة فعلًا في مؤسستك. والبرنامج **الشائع** يؤدي مهمة تحتاجها كل مؤسسة: المحاسبة والرواتب والبريد ومكتب مساعدة قياسي ونظام علاقات عملاء بسيط. واختبار بسيط: إن استطاع منافس أن يشتري الأداة نفسها ويحصل على النتيجة نفسها فهي شائعة، ولن تكسب شيئًا من بنائها.

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

العوامل التي تحسم القرار

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

لا شيء منهما مجاني، والجواب الصادق عن «أيهما أرخص؟» هو «يعتمد». وجدول يضع الخيارين جنبًا إلى جنب عبر سنوات عدة يكشف في الغالب أيهما يناسبك. وإن اخترت البناء فإن شكل التعاقد يغيّر مخاطرتك، فراجع [نماذج التسعير](/company/pricing-models).

المنتج الجاهز يحتفظ ببياناتك بصيغته ووفق جدوله. فقبل أن توقّع اسأل: كيف أصدّر كل شيء؟ وهل توجد واجهة برمجية موثقة؟ وماذا يحدث لبياناتي إن غادرت أو أغلق المزوّد أبوابه؟ أما البناء المخصص فيمنحك البيانات وخارطة الطريق، لكن بشرط أن ينص الاتفاق على أنك تملك الشيفرة والحسابات. اتفق على ذلك كتابةً قبل بدء العمل.

الشراء لا ينقل مسؤوليتك إلى المزوّد. فأنت ما زلت من يقرر من يصل إلى النظام وما البيانات التي تدخله، وهل استضافة المزوّد وضوابطه تفي بالتزاماتك، فاطلب أدلة لا مجرد تصريحات. والبناء يمنحك التحكم في نموذج التهديدات، ويحمّلك أيضًا واجب العمل: نمذجة التهديدات، والبرمجة الآمنة، والاختبار، والمراجعة قبل الإطلاق. وتأكد من الالتزامات القانونية مع مستشار قانوني مؤهل. ونهجنا في ذلك في دليل [تطوير التطبيقات الآمنة](/guides/secure-app-development).

الشراء يوصلك إلى أول يوم عمل أسرع. لكن المزوّد هو من يحدد خارطة الطريق، وقد يغيّر التسعير أو يوقف ميزة أو يُستحوذ عليه. أما البناء فله مخاطره: التأخير، وتوسّع النطاق، والاعتماد على الفريق الذي بناه.

الطريق الوسط: اضبط، ثم بدون كود، ثم مخصص

فكّر في سُلّم لا في مفترق طرق. كل درجة تمنحك تحكمًا أكبر وتتطلب جهدًا أكبر:

ابدأ من أدنى درجة تسمح بها المشكلة، وحدّد مسبقًا ما الذي سيدفعك إلى الصعود: تكلفة تنمو أسرع من القيمة، أو حدّ لا تتجاوزه المنصة، أو متطلب بيانات أو أمن لا تستوفيه، أو أداء يتدهور تحت الحمل. وخطّط للخروج منذ اليوم الأول: أبقِ البيانات نظيفة، ووثّق المنطق، وتحقق من قدرتك على تصدير كل شيء.

قائمة تحقق للقرار

أجب بصدق. في الأسئلة الأربعة الأولى تميل «نعم» نحو البناء. أما الأربعة الأخيرة فتحدد كيف تبني أو تشتري، لا هل تفعل.

كثرة «نعم» في الأسئلة الأربعة الأولى تستحق نظرة أقرب إلى البرمجيات المخصصة، وغيابها يرجّح الشراء. ولمسار أكثر تفصيلًا اقرأ دليل [اختيار طريقة بناء منتجك](/guides/choosing-how-to-build-your-product).

ثلاثة سيناريوهات افتراضية

هذه أمثلة متخيَّلة لتوضيح طريقة التفكير، وليست عملًا لعميل.

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

منطق التوزيع عندها هو ما يتفوق به على منافسيها، ولا يناسبها منتج إلا بحلول التفافية. ابنِ هذا الجزء مخصصًا، واشترِ المحاسبة والتوقيع الإلكتروني والمراسلة. واربطها عبر واجهات برمجية API ليتغير كل جزء بمعزل عن الآخر.

الخطر الرئيسي هو هل يريدها أحد، لا هل تتسع للنمو. ابنِ النسخة الأولى على منصة بدون كود، وتعلّم من الاستخدام الفعلي، ودوّن محفزات الانتقال إلى الشيفرة المخصصة. ويتعمق مقال [متى يكون بدون كود أذكى نسخة أولى](/blog/when-no-code-is-the-smart-first-version) في هذا.