KISS або помри: чому досвідчені інженери зазнають невдачі у стартапах

Мій перший стартап був невдалим, і кілька сусідніх стартапів також зазнали невдачі. У нас було: $100K у кредитах GCP, інженер-засновник, який створював системи для підприємств, і вихід на ринок. І ми зазнали невдачі не тому, що побудували це неправильно, а тому, що побудували це добре. У цьому і була проблема.

Поки ми витрачали час на боротьбу з тим, що здавалося "неоптимальним" технічним стеком, ми втратили найважливіше: час, імпульс і стратегічну можливість.

Ця історія не про людей без здорового глузду. У мене був здоровий глузд, і ми знали, що повинні тримати речі простими. Але коли ваша ментальна модель не відповідає ситуації, весь ваш здоровий глузд зникає. Ви приймаєте "правильні" рішення, які вас вбивають.

Це також не історія про погану інженерію. Це про те, як хороша інженерія вбиває стартапи. Як саме той досвід, який робить вас старшим, стає вашим найбільшим зобов'язанням. Як "робити правильно" або навіть "робити просто" часто означає робити неправильно.

Ця стаття представляє ментальні моделі, щоб допомогти вам приймати правильні рішення та уникати неправильних, які зробив я.

:::tip Для кого це: старші інженери, які починають або приєднуються до стартапів на ранній стадії. Якщо ви провели 5+ років на підприємстві або у великій технологічній компанії, це ваше попередження.

:::

\

Ментальна модель №1 - "Безкоштовна" інфраструктура є найдорожчою

$100K у кредитах 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 чудовий, і наш інженер міг побудувати з ним що завгодно.

Але "що завгодно" займало час просто для початку. Налаштування розгортання, аутентифікації та базових компонентів 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% того, що ви знаєте, і доставляти сьогоднішнє рішення, а не завтрашню архітектуру.