KISS or Die: Чому старші інженери провалилися на стартапах

Мій перший стартап був невдалим, і кілька сусідніх стартапів також зазнали невдачі.У нас було: $ 100 000 в кредитах GCP, засновник-інженер, який побудував системи на підприємстві, і пішов на ринок.І ми зазнали невдачі, не тому, що ми побудували його неправильно, а тому, що ми побудували його добре. У той час як ми витрачали час на боротьбу з тим, що здалося «неоптимальним» технологічним стеком, ми втратили найважливіше: час, імпульс і стратегічно можливість. Ця історія не про людей без здорового глузду.У мене був здоровий глузд, і ми знали, що ми повинні тримати речі простими.Але коли ваша психічна модель не вписується в ситуацію, весь ваш здоровий глузд знімається.Ви приймаєте «правильні» рішення, які вбивають вас. Це також не історія про погану інженерію. Це про те, як хороша інженерія вбиває стартапи. Як саме досвід, який робить вас старшим, стає вашою найбільшою відповідальністю. Ця стаття представляє Для того, щоб допомогти вам зробити Уникайте тих помилок, які я зробив. mental models right Для кого це: старші інженери, які починають або приєднуються до стартапів на ранній стадії. Якщо ви витратили 5+ років на підприємство або Big Tech, це ваше попередження. Для кого це: старші інженери, які починають або приєднуються до стартапів на ранній стадії. Якщо ви витратили 5+ років на підприємство або Big Tech, це ваше попередження. Для кого це: Психічна модель # 1 - «безкоштовна» інфраструктура найдорожча 100 000 доларів в кредитах GCP здається подарунком, але це пастка. Це підштовхує вас до надінженерії, тому що «це вже оплачено». Ви отримуєте обчислювальні інстанції, балансири навантаження, реєстри контейнерів та інструменти підприємства, які вимагають установки підприємства. Звичайно, ви можете створювати робочі потоки «розподіл з GitHub в VM» на GCP/AWS/Azure. Деякі продукти наближаються. Але це вимагає додаткових кроків: налаштування Cloud Build, налаштування ролей IAM, написання сценаріїв розгортання, управління секретами та налаштування перевірок здоров'я. Ви витрачаєте час на створення інфраструктури розгортання, перш ніж розгортати реальні продукти. Крім того, такі платформи як або надати вам те, що дійсно потрібно стартапам: наполегливий VM з розгортанням Start-and-Go з GitHub. Легко, як це може бути: ви натискаєте свій код, і він розгортається. Просто готовий використовувати VM з перемінними середовищами, SSL, балансерами навантаження, журналами і т.д. Це не «безкоштовно», але це готово. Railway Fly.io Безкоштовні кредити підштовхують вас до надмірної інженерії, тому що "воно вже оплачено".Ви переконуєте себе, що заощаджуєте гроші, витрачаючи свій найцінніший ресурс: час. Ментальна модель Ви будете витрачати тижні на встановлення «правильної» інфраструктури, але конкуренти запустили за два дні на Heroku. Або вони отримали 1000 користувачів, поки ми працюємо над трубопровідником. Ці користувачі варті більше, ніж безкоштовні кредити. Навіть коли ви уникаєте цього, є більш глибока проблема: як вищі інженери думають про саму простоту. Ментальна модель Ви будете витрачати тижні на встановлення «правильної» інфраструктури, але конкуренти запустили за два дні на Heroku. Або вони отримали 1000 користувачів, поки ми працюємо над трубопровідником. Ці користувачі варті більше, ніж безкоштовні кредити. Навіть коли ви уникаєте цього, є більш глибока проблема: як вищі інженери думають про саму простоту. Психічна модель #2 – «мінімальна» <> «проста» Традиційний принцип KISS говорить нам, щоб наше програмне забезпечення було простим, але в стартапах це неправильна мета. Справжня простота повинна вимірюватися загальними зусиллями, а не складністю коду: Total Effort = Initial Build + Maintenance + Debugging + Feature Addition + Security Updates + Scaling Changes Коли ви будуєте з нуля, ви володієте всіма цими назавжди. Коли ви використовуєте послугу, більшість з них стають нульовими. My OAuth Example Один тиждень пізніше він подав PR: чиста реалізація OAuth з токенами JWT, оновлення обертання токенів, управління сесіями та управління доступом на основі ролей. Я не заперечував PR. І це було помилкою. Викидання тижня роботи зламало б мораль. Але це створює складність коду і ставить його на неправильні рейки. Плюс, не обговорювати підхід заздалегідь було нашою справжньою помилкою. Ми дозволяємо інженерній гордості приймати стратегічне рішення. Потім клієнту знадобився Microsoft OAuth і Google OAuth. Налаштована реалізація означала дні рефакторизації, обновити обертання токенів, випадки краю, RBA та інші речі. Кожне "просте" додавання вимагало глибокого розуміння нашого налаштованого автору. Кожне оновлення безпеки було нашим для реалізації. Principles Класична помилка старшого інженера: оптимізація для контролю, а не результатів.У стартапах реальність вимагає повного переоцінки того, як думають старші інженери: Припиніть думати: "Це всього кілька днів кодування"Старт думати: "Це кілька днів НЕ кодування мого фактичного продукту" Припиніть думати: "Я можу побудувати це просто"Стартуйте думати: "Я можу вирішити це просто не будуючи" СТОП думки: "Послуги третіх сторін додають складності"СТАП думки: "Послуги третіх сторін поглинають складність" Ментальна модель У стартапах, KISS означає бути ледачим про все, крім вашого основного продукту. Не ледачий в якості, але ледачий в зусиллях. Тому що кожна година, витрачена на відновлення вирішених проблем, - це година, вкрадена від невирішених проблем, які насправді визначають, чи живе ваш стартап або вмирає. Ментальна модель У стартапах, KISS означає бути ледачим про все, крім вашого основного продукту. Не ледачий в якості, але ледачий в зусиллях. Тому що кожна година, витрачена на відновлення вирішених проблем, - це година, вкрадена від невирішених проблем, які насправді визначають, чи живе ваш стартап або вмирає. Ментальна модель #3 - вибір комфорту Ми вибрали Angular, тому що наш засновник інженер знав це глибоко. Розумне рішення, чи не так? Використовуйте свої сильні сторони, код якості судна. The Ecosystem Trap Angular відмінний і наш інженер міг побудувати все з ним. Налаштування розгортання, аутентифікації та базових компонентів інтерфейсу означало нескінченну конфігурацію перед написанням однієї функції.У той час як ми дебютували теми Angular Material, конкуренти можуть (і будуть) використовувати Next.js + Vercel вже були на борту користувачів. Просто порівняйте це з шляхом Next.js + Vercel: розгорніть додаток для скелетів з додатком npx create-next на перший день, додайте аутентифікацію Clerk та компоненти shadcn / ui, відправте фактичні функції на перший день. Why does this happen? Різниця полягає не в якості рамки, а в оптимізації екосистеми. Next.js/React оточений інструментами для створення стартапів для інших стартапів: UI: shadcn/ui - копіювати, пасти, корабель Auth: Clerk/Supabase - конфігуруйте за кілька хвилин Розробка: Vercel - git push equals production Все інше: якщо стартапи потребують цього, хтось побудував послугу Екосистема Angular служить підприємствам: потужна, гнучка, нескінченно налаштувана. ідеально підходить для команд з 50 осіб і отрута для команд з 3. Ментальна модель Цей вибір показав важливу відмінність: Framework Senior: "Я освоїв Angular. Я можу побудувати все з ним." Вони оптимізують для якості коду та "правильних" інженерних практик. Чи потрібна таблиця даних? Вони витратять два тижні на створення ідеально абстрактного, сторінкованого компонента - для ваших 50 рядків даних. Прикладний старший: "Я знаю Angular, але Next.js кораблі 3 рази швидше. Давайте використаємо це." Вони оптимізують для зворотного зв'язку з ринком. Вони завантажують всі дані на стороні клієнта, тому що "ми не будемо досягати масштабу протягом місяців" і поставляти з офшорними компонентами. Їхній код може бути забутовим, але вони повторюють функцію три, тоді як Framework Senior все ще вдосконалює свою абстракцію сторінки. По-справжньому старший крок полягає в тому, щоб запитати себе: "Чи я вирішу завтрашні проблеми чи сьогоднішні можливості?" Вибір правильної екосистеми має значення. Ментальна модель Цей вибір показав важливу відмінність: Framework Senior: "Я освоїв Angular. Я можу побудувати все з ним." Вони оптимізують для якості коду та "правильних" інженерних практик. Чи потрібна таблиця даних? Вони витратять два тижні на створення ідеально абстрактного, сторінкованого компонента - для ваших 50 рядків даних. Прикладний старший: "Я знаю Angular, але Next.js кораблі 3 рази швидше. Давайте використаємо це." Вони оптимізують для зворотного зв'язку з ринком. Вони завантажують всі дані на стороні клієнта, тому що "ми не будемо досягати масштабу протягом місяців" і поставляти з офшорними компонентами. Їхній код може бути забутовим, але вони повторюють функцію три, тоді як Framework Senior все ще вдосконалює свою абстракцію сторінки. : « " The truly senior move is asking yourself Я вирішую завтрашні проблеми чи сьогоднішні можливості? Вибір правильної екосистеми має значення. Ментальна модель #4 - Будівництво ядра, рентабельний контекст Але навіть з правильними інструментами, є одна остаточна пастка: примус будувати речі, тому що ви можете, а не тому, що ви повинні. Ми витратили щонайменше місяць в цілому на функції, які ніхто не потребував. Налаштований OAuth, коли існував Auth0. Постгрес-базова черга роботи, коли існував Redis + Celery. Terraform з першого дня, коли консоль працювала добре. Кожне рішення відчувало себе продуктивним, але кожен був само-саботажем, щоб зіткнутися з реальними викликами, такими як розмова з клієнтами або робити інший розвиток клієнтів. Модель проста: якщо клієнти не виберуть вас для цього, не будуйте його. My $50 Rule Якщо SaaS коштує менше 50 доларів на місяць, ви не можете собі дозволити побудувати його. Будівництво налаштованого OAuth займає 1-2 тижні в загальному обслуговуванні та додаванні різних постачальників OAuth. При стартапах, це $ 5000-$ 15 000 в інженерному часі, або в час втраченої можливості. Auth0 безкоштовно для до 25 000 активних користувачів, потім $ 35 / місяць. Ви могли б заплатити за Auth0 протягом 35 років за те, що це коштує, щоб побудувати його один раз. Отже, мова йде не про гроші, а про пріоритети і вартість можливостей. Exception На мою думку, будуйте тільки в тому випадку, якщо ви не можете дізнатися про користувачів без нього. Простий приклад полягає в тому, коли вам потрібно перевірити, чи будуть користувачі платити за звіти, створені AI. Будуйте найпростішу версію, яка підтверджує попит. І все інше намагається слізти. Так, пропустити інфраструктуру, пропустити "робити це правильно", пропустити кращі практики, які не поставляють функції, пропустити тести. Again, be as lazy as possible in writing code. What I Actually Use Auth: Clerk (React-native, краще DX) або Auth0 (B2B-фокусований, готовий до бізнесу) Електронна пошта: Resend (розробник-перший) або SendGrid (бойове тестування) Аналітика: PostHog (безкоштовно до масштабування) Моніторинг: Sentry (непереможний для помилок) Хостинг: Cloudflare або Vercel (якщо все в Next.js) Це не схвалення, а мої власні вибори, оптимізовані для швидкості. я думаю, що ваш стек буде відрізнятися, але цей принцип не буде. Ментальна модель Якщо клієнти бачать це і вибирають вас для цього, побудуйте його. Все інше, спробуйте орендувати: auth, електронні листи, платежі, моніторинг ... що завгодно. Ваш стартап не помре від використання Auth0, але він помре від витрати трьох тижнів на аутентифікацію будівництва, тоді як конкуренти хочуть, щоб користувачі використовували функції судна. Ментальна модель Якщо клієнти бачать це і вибирають вас для цього, побудуйте його. Все інше, спробуйте орендувати: auth, електронні листи, платежі, моніторинг ... що завгодно. Ваш стартап не помре від використання Auth0, але він помре від витрати трьох тижнів на аутентифікацію будівництва, тоді як конкуренти хочуть, щоб користувачі використовували функції судна. Нижня лінія LLM мають товарне будівництво. Будь-який молодший з Клодом може створити цю налаштовану систему, на яку ви так пишаєтеся. Ваша цінність не в тому, що ви більше можете побудувати, але це в знанні того, чого не будувати. Справжня старшість означає мати дисципліну ігнорувати 90% того, що ви знаєте, і відправляти сьогоднішнє рішення, а не архітектуру завтрашнього дня.