قبّل أو مت: لماذا يفشل المهندسون الكبار في الشركات الناشئة

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

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

هذه القصة ليست عن أشخاص بدون حس سليم. كان لدي حس سليم، وكنا نعلم أنه يجب علينا الحفاظ على بساطة الأمور. ولكن عندما لا يتناسب نموذجك الذهني مع الموقف، يتم اجتياح كل حسك السليم. تتخذ قرارات "صحيحة" تقتلك.

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

تقدم هذه المقالة نماذج ذهنية لمساعدتك على اتخاذ القرارات الصحيحة وتجنب القرارات الخاطئة التي اتخذتها.

:::tip لمن هذا: المهندسين الكبار الذين يبدأون أو ينضمون إلى الشركات الناشئة في مراحلها المبكرة. إذا كنت قد قضيت أكثر من 5 سنوات في المؤسسات أو شركات التكنولوجيا الكبرى، فهذا تحذيرك.

:::

\

النموذج الذهني #1 - البنية التحتية "المجانية" هي الأكثر تكلفة

يبدو 100 ألف دولار في رصيد GCP وكأنه هدية، لكنه فخ. يدفعك نحو الإفراط في الهندسة لأنه "مدفوع بالفعل". تحصل على مثيلات الحوسبة، وموازنات الحمل، وسجلات الحاويات، وأدوات المؤسسات التي تتطلب إعدادًا للمؤسسات. ما الذي تحتاج إلى الحصول عليه؟ زر "دفع للنشر".

بالتأكيد، يمكنك بناء سير عمل "النشر من GitHub إلى VM" على GCP/AWS/Azure. بعض المنتجات تقترب من ذلك. لكنه يتطلب خطوات إضافية: تكوين Cloud Build، وإعداد أدوار IAM، وكتابة نصوص النشر، وإدارة الأسرار، وتكوين فحوصات الصحة. تحرق الوقت في بناء بنية تحتية للنشر قبل نشر المنتجات الفعلية.

في الوقت نفسه، توفر منصات مثل Railway أو Fly.io ما تحتاجه الشركات الناشئة بالفعل: VM مستمرة مع نشر سريع من GitHub. سهل كما يمكن أن يكون: تدفع الكود الخاص بك، ويتم نشره. مجرد VM جاهزة للاستخدام مع متغيرات البيئة، وSSL، وموازنات الحمل، والسجلات، إلخ. ليست "مجانية"، لكنها جاهزة.

تدفعك الأرصدة المجانية نحو الإفراط في الهندسة لأنها "مدفوعة بالفعل". تقنع نفسك بأنك توفر المال بينما تنفق أثمن مواردك: الوقت.

\

النموذج الذهني #2 - "الحد الأدنى" <> "البسيط"

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

يجب قياس البساطة الحقيقية من خلال إجمالي الجهد، وليس تعقيد الكود:

إجمالي الجهد = البناء الأولي + الصيانة + تصحيح الأخطاء + إضافة الميزات + تحديثات الأمان + تغييرات التوسع

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

مثال OAuth الخاص بي

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

لم أرفض PR. وكان هذا خطأ. إن التخلي عن أسبوع من العمل سيحطم الروح المعنوية. لكنه يخلق تعقيدًا في الكود ويضعه على المسارات الخاطئة. بالإضافة إلى ذلك، كان عدم مناقشة النهج مسبقًا هو خطأنا الحقيقي. سمحنا لفخر الهندسة باتخاذ قرار استراتيجي.

ثم، احتاج عميل إلى Microsoft OAuth و Google OAuth. التنفيذ المخصص يعني أيامًا من إعادة الهيكلة، وتناوب رمز التحديث، والحالات الحدية، وRBA، وأشياء أخرى. كل إضافة "بسيطة" تطلبت فهمًا عميقًا لمصادقتنا المخصصة. كل تحديث أمني كان علينا تنفيذه. كل متطلب جديد كان علينا ترميزه.

المبادئ

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

1. توقف عن التفكير: "هذه مجرد بضعة أيام من الترميز" \n ابدأ التفكير: "هذه بضعة أيام لا أقوم فيها بترميز منتجي الفعلي"
2. توقف عن التفكير: "يمكنني بناء هذا ببساطة" \n ابدأ التفكير: "يمكنني حل هذا ببساطة عن طريق عدم البناء"
3. توقف عن التفكير: "خدمات الطرف الثالث تضيف تعقيدًا" \n ابدأ التفكير: "خدمات الطرف الثالث تمتص التعقيد"

\

\

النموذج الذهني #3 - خيارات الراحة

اخترنا Angular لأن مهندسنا المؤسس كان يعرفه بعمق. قرار ذكي، أليس كذلك؟ استخدم نقاط قوتك، وأرسل كودًا عالي الجودة. كان الإطار جيدًا، ولكن المشكلة كانت في نظامه البيئي.

فخ النظام البيئي

Angular ممتاز ويمكن لمهندسنا بناء أي شيء به.

لكن "أي شيء" استغرق وقتًا للبدء. إعداد النشر، والمصادقة، ومكونات واجهة المستخدم الأساسية يعني تكوينًا لا نهاية له قبل كتابة ميزة واحدة. بينما كنا نصحح أخطاء سمات Angular Material، يمكن للمنافسين (وسيفعلون) استخدام Next.js + Vercel وكانوا يقومون بالفعل بتسجيل المستخدمين.

قارن ذلك بمسار Next.js + Vercel: انشر تطبيقًا هيكليًا باستخدام npx create-next-app في اليوم الأول، أضف مصادقة Clerk ومكونات shadcn/ui، وأرسل الميزات الفعلية في اليوم الأول. نفس الوجهة، رحلة مختلفة تمامًا.

لماذا يحدث هذا؟

الفرق ليس في جودة الإطار، بل في تحسين النظام البيئي. Next.js/React محاط بشركات ناشئة مدعومة من رأس المال الاستثماري تبني أدوات للشركات الناشئة الأخرى:

• واجهة المستخدم: shadcn/ui - نسخ، لصق، شحن
• المصادقة: Clerk/Supabase - تكوين في دقائق
• النشر: Vercel - git push يساوي الإنتاج
• كل شيء آخر: إذا كانت الشركات الناشئة بحاجة إليه، فقد بنى شخص ما خدمة

يخدم النظام البيئي لـ Angular المؤسسات: قوي، مرن، قابل للتخصيص بلا حدود. مثالي(؟) لفرق من 50 وسم لفرق من 3.

\

النموذج الذهني #4 - بناء الجوهر، استئجار السياق

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

قضينا شهرًا على الأقل في المجموع على ميزات لا يحتاجها أحد. OAuth مخصص عندما كان Auth0 موجودًا. قائمة انتظار وظائف تعتمد على Postgres عندما كان Redis + Celery موجودًا. Terraform من اليوم الأول، عندما كانت وحدة التحكم تعمل بشكل جيد. كل قرار شعر بأنه منتج، لكن كل منها كان تخريبًا ذاتيًا لمواجهة التحديات الحقيقية مثل التحدث إلى العملاء أو القيام بتطوير العملاء الآخرين.

النمط بسيط: إذا لن يختارك العملاء من أجله، فلا تبنيه.

قاعدة الـ 50 دولار الخاصة بي

إذا كانت تكلفة SaaS أقل من 50 دولارًا شهريًا، فلا يمكنك تحمل تكلفة بنائها. وقتك باهظ الثمن للغاية.

يستغرق بناء OAuth المخصص 1-2 أسبوع في إجمالي الصيانة وإضافة موفري OAuth مختلفين. بمعدلات حرق الشركات الناشئة، هذا 5000-15000 دولار في وقت الهندسة، أو في وقت فقدان الفرصة. Auth0 مجاني لما يصل إلى 25000 مستخدم نشط، ثم 35 دولارًا شهريًا. يمكنك الدفع مقابل Auth0 لمدة 35 عامًا بما يكلفك بناؤه مرة واحدة.

إذن، هذا ليس متعلقًا بالمال ولكن بالأولويات وتكلفة الفرصة.

استثناء

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

ما أستخدمه بالفعل

• المصادقة: Clerk (React-native، تجربة مطور أفضل) أو Auth0 (موجه للأعمال التجارية بين الشركات، جاهز للمؤسسات)
• البريد الإلكتروني: Resend (للمطورين أولاً) أو SendGrid (مختبر في المعارك)
• التحليلات: PostHog (مجاني حتى التوسع)
• المراقبة: Sentry (لا يضاهى للأخطاء)
• الاستضافة: Cloudflare أو Vercel (إذا كنت تستخدم Next.js بالكامل)

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

\

\

الخلاصة

لقد جعلت نماذج اللغة الكبيرة (LLMs) البناء سلعة. يمكن لأي مبتدئ مع Claude إنشاء نظام المصادقة المخصص الذي تفتخر به. قيمتك ليست فيما يمكنك بناؤه بعد الآن، ولكن في معرفة ما لا يجب بناؤه.

القيادة هي القدرة على فصل الإشارات عن الضوضاء. الأقدمية الحقيقية تعني امتلاك الانضباط لتجاهل 90٪ مما تعرفه وشحن حل اليوم، وليس هندسة الغد.