ساده سازی یا مرگ: چرا مهندسان ارشد در شرکت‌های نوآفرین شکست می‌خورند

اولین شرکت نوآفرین من شکست خورد، و چندین شرکت نوآفرین مجاور نیز شکست خوردند. ما داشتیم: 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 را رد نکردم. و این یک اشتباه بود. دور انداختن یک هفته کار روحیه را نابود می‌کرد. اما پیچیدگی کد ایجاد می‌کند و آن را روی ریل‌های اشتباه قرار می‌دهد. علاوه بر این، عدم بحث درباره رویکرد از قبل اشتباه واقعی ما بود. ما اجازه دادیم غرور مهندسی یک تصمیم استراتژیک بگیرد.

سپس، یک مشتری به OAuth مایکروسافت و OAuth گوگل نیاز داشت. پیاده‌سازی سفارشی به معنای روزها بازسازی، چرخش توکن تازه‌سازی، موارد حاشیه‌ای، RBA و چیزهای دیگر بود. هر افزودن "ساده" نیاز به درک عمیق از احراز هویت سفارشی ما داشت. هر به‌روزرسانی امنیتی برای ما بود که پیاده‌سازی کنیم. هر نیاز جدید برای ما بود که کد بنویسیم.

اصول

اشتباه کلاسیک مهندس ارشد: بهینه‌سازی برای کنترل به جای نتایج. در شرکت های نوآفرین، واقعیت نیاز به معکوس کردن کامل نحوه تفکر مهندسان ارشد دارد:

1. توقف تفکر: "این فقط چند روز کدنویسی است" \n شروع تفکر: "این چند روز عدم کدنویسی محصول واقعی من است"
2. توقف تفکر: "من می‌توانم این را به سادگی بسازم" \n شروع تفکر: "من می‌توانم این را به سادگی با نساختن حل کنم"
3. توقف تفکر: "سرویس‌های شخص ثالث پیچیدگی اضافه می‌کنند" \n شروع تفکر: "سرویس‌های شخص ثالث پیچیدگی را جذب می‌کنند"

\

\

مدل ذهنی #3 - انتخاب‌های راحتی

ما Angular را انتخاب کردیم زیرا مهندس بنیانگذار ما آن را عمیقاً می‌شناخت. تصمیم هوشمندانه‌ای است، درست است؟ از نقاط قوت خود استفاده کنید، کد با کیفیت ارسال کنید. فریم‌ورک خوب بود، اما مشکل اکوسیستم آن بود.

تله اکوسیستم

Angular عالی است و مهندس ما می‌توانست هر چیزی را با آن بسازد.

اما "هر چیزی" فقط برای شروع زمان می‌برد. راه‌اندازی استقرار، احراز هویت و اجزای پایه UI به معنای پیکربندی بی‌پایان قبل از نوشتن یک ویژگی واحد بود. در حالی که ما تم‌های Angular Material را اشکال‌زدایی می‌کردیم، رقبا می‌توانند (و خواهند) از Next.js + Vercel استفاده کنند که قبلاً در حال ثبت‌نام کاربران بودند.

فقط آن را با مسیر Next.js + Vercel مقایسه کنید: استقرار یک برنامه اسکلتی با npx create-next-app در روز اول، افزودن احراز هویت Clerk و اجزای shadcn/ui، ارسال ویژگی‌های واقعی در روز اول. مقصد یکسان، سفر کاملاً متفاوت.

چرا این اتفاق می‌افتد؟

تفاوت در کیفیت فریم‌ورک نیست، بلکه در بهینه‌سازی اکوسیستم است. Next.js/React توسط شرکت های نوآفرین با پشتیبانی سرمایه‌گذاری خطرپذیر احاطه شده است که ابزارهایی برای سایر شرکت های نوآفرین می‌سازند:

• UI: shadcn/ui - کپی، پیست، ارسال
• احراز هویت: Clerk/Supabase - پیکربندی در دقایق
• استقرار: Vercel - git push برابر با تولید
• همه چیز دیگر: اگر شرکت های نوآفرین به آن نیاز داشته باشند، کسی یک سرویس ساخته است

اکوسیستم Angular به سازمان‌ها خدمت می‌کند: قدرتمند، انعطاف‌پذیر، بی‌نهایت قابل سفارشی‌سازی. عالی(؟) برای تیم‌های 50 نفره و سمی برای تیم‌های 3 نفره.

\

مدل ذهنی #4 - هسته را بسازید، زمینه را اجاره کنید

اما حتی با ابزارهای مناسب، یک تله نهایی وجود دارد: اجبار به ساختن چیزها به این دلیل که می‌توانید، نه به این دلیل که باید. این تله تیم‌های فنی قوی و شرکت های نوآفرین بیشتری را از آنچه می‌توانیم تصور کنیم می‌کشد: ساختن چیزهایی که هیچ کس نخواسته است زیرا می‌توانید، نه به این دلیل که باید.

ما حداقل یک ماه در مجموع روی ویژگی‌هایی که هیچ کس به آنها نیاز نداشت صرف کردیم. OAuth سفارشی وقتی Auth0 وجود داشت. یک صف کار مبتنی بر Postgres وقتی Redis + Celery وجود داشت. Terraform از روز اول، وقتی کنسول به خوبی کار می‌کرد. هر تصمیم احساس مولد بودن می‌داد، اما هر کدام خودزنی برای مواجهه با چالش‌های واقعی مانند صحبت با مشتریان یا انجام توسعه مشتری دیگر بود.

الگو ساده است: اگر مشتریان شما را برای آن انتخاب نمی‌کنند، آن را نسازید.

قانون 50 دلاری من

اگر یک SaaS کمتر از 50 دلار در ماه هزینه دارد، شما نمی‌توانید آن را بسازید. زمان شما بسیار گران است.

ساخت OAuth سفارشی 1-2 هفته در مجموع نگهداری و افزودن ارائه‌دهندگان مختلف OAuth طول می‌کشد. با نرخ سوختن شرکت نوآفرین، این 5,000-15,000 دلار در زمان مهندسی، یا در زمان از دست دادن فرصت است. Auth0 برای تا 25,000 کاربر فعال رایگان است، سپس 35 دلار در ماه. شما می‌توانید برای Auth0 به مدت 35 سال با آنچه که هزینه ساخت آن یک بار است پرداخت کنید.

بنابراین، این درباره پول نیست بلکه درباره اولویت‌ها و هزینه فرصت است.

استثنا

به نظر من، فقط در صورتی بسازید که نمی‌توانید بدون آن درباره کاربران یاد بگیرید.  یک مثال ساده زمانی است که نیاز دارید آزمایش کنید آیا کاربران برای گزارش‌های تولید شده توسط هوش مصنوعی پرداخت می‌کنند. ساده‌ترین نسخه‌ای را بسازید که تقاضا را ثابت می‌کند. و همه چیز دیگر سعی می‌کند بلغزد. بله، زیرساخت را رد کنید، "انجام درست" را رد کنید، بهترین شیوه‌هایی که ویژگی‌ها را ارسال نمی‌کنند را رد کنید، آزمون‌ها را رد کنید. دوباره، در نوشتن کد تا حد امکان تنبل باشید.

آنچه من واقعاً استفاده می‌کنم

• احراز هویت: Clerk (React-native، DX بهتر) یا Auth0 (متمرکز بر B2B، آماده سازمان)
• ایمیل: Resend (اول توسعه‌دهنده) یا SendGrid (آزمایش شده در نبرد)
• تجزیه و تحلیل: PostHog (رایگان تا مقیاس)
• نظارت: Sentry (برای خطاها غیرقابل شکست)
• میزبانی: Cloudflare یا Vercel (اگر کاملاً روی Next.js هستید)

اینها تأییدیه نیستند بلکه انتخاب‌های خود من بهینه‌سازی شده برای سرعت هستند. حدس می‌زنم استک شما متفاوت خواهد بود اما این اصل متفاوت نخواهد بود.

\

\

نتیجه نهایی

LLMها ساختن را کالایی کرده‌اند. هر جونیور با Claude می‌تواند آن سیستم احراز هویت سفارشی را که شما به آن افتخار می‌کنید ایجاد کند. ارزش شما دیگر در آنچه می‌توانید بسازید نیست، بلکه در دانستن آنچه نباید بسازید است.

رهبری توانایی جدا کردن سیگنال‌ها از نویز است. ارشدیت واقعی به معنای داشتن نظم برای نادیده گرفتن 90٪ از آنچه می‌دانید و ارسال راه‌حل امروز، نه معماری فردا است.