هل ينبغي لشركتك بناء برمجياتها الداخلية الخاصة في عام 2026؟ (لقد فعلنا ذلك)

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

لماذا انقلبت كفة "البناء مقابل الشراء" لصالح الأدوات الداخلية؟

لأن تكلفة البناء انهارت بينما استمرت تكلفة الاستئجار في الارتفاع. تشغل الشركة المتوسطة الآن 106 تطبيقات SaaS (برمجيات قائمة على الاشتراك، تُدفع شهريًا أو سنويًا)¹، وكان من المتوقع أن يصل الإنفاق العالمي على SaaS إلى 299 مليار دولار في عام 2025، ارتفاعًا من حوالي 251 مليار دولار في العام السابق². هذه الأرقام دقيقة حتى تاريخ النشر؛ يرجى التعامل مع هذه التفاصيل كصورة عامة مؤقتة لسوق سريعة الحركة.

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

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

ما الذي بنيناه بالفعل؟

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

ومنذ ذلك الحين، استمرت القائمة في النمو: تتبع الفعاليات، وأداة بناء المقترحات لعروض أسعار المبيعات، وأداة الدردشة داخل التطبيق. والخطوة التالية هي اشتراكات أتمتة التسويق، ونظام إدارة علاقات العملاء (CRM)، وإدارة المشاريع. لقد تم بناء كل أداة عندما فشلت النسخة المشتراة في تلبية سير عمل محدد وواضح.

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

ما هي البرمجيات التي لا يزال يتعين عليك شراؤها؟

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

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

لقد اتبعنا قاعدتنا الخاصة هنا؛ حيث بنينا أدوات المحتوى والتتبع فوق البنية التحتية للتجارة التي نشغلها بالفعل، ولم نعد بناء مسارات الدفع. وننصحك بألا تحاول القيام بذلك.

كيف تقرر ما الذي ستبنيه أولاً؟

لقد ساعدتنا ثلاثة أسئلة في تصفية قائمتنا بشكل جيد:

• إذا تعطلت هذه الأداة في يوم الثلاثاء، فهل سيكون ذلك مجرد إزعاج أم كارثة؟ ابنِ أدوات الإزعاج أولاً.

• هل تفشل النسخة المشتراة في تلبية سير عمل محدد وواضح؟ عبارة "الفاتورة تزعجني" ليست مواصفة فنية، بينما عبارة "البحث لا يمكنه العثور على نصف مقالاتنا" هي كذلك.

• من سيكون مسؤولاً عنها بعد عام؟ تحتاج كل أداة داخلية إلى شخص واحد يكون مسؤولاً عنها. إذا لم يكن هناك مسؤول، فلا تبنِها.

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

إذًا، هل ينبغي لشركتك بناء برمجياتها الداخلية الخاصة في عام 2026؟

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

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