KISS или умри: Почему опытные инженеры терпят неудачу в стартапах

Мой первый стартап потерпел неудачу, как и несколько соседних стартапов. У нас было: 100K $ в кредитах GCP, основатель-инженер, который создавал системы для предприятий, и выход на рынок. И мы потерпели неудачу не потому, что построили это неправильно, а потому, что построили это хорошо. В этом и была проблема.

Пока мы тратили время на борьбу с тем, что казалось "неоптимальным" технологическим стеком, мы потеряли самое важное: время, импульс и стратегическую возможность.

Эта история не о людях без здравого смысла. У меня был здравый смысл, и мы знали, что должны держать вещи простыми. Но когда ваша ментальная модель не соответствует ситуации, весь ваш здравый смысл исчезает. Вы принимаете "правильные" решения, которые вас убивают.

Это также не история о плохой инженерии. Это о том, как хорошая инженерия убивает стартапы. Как именно тот опыт, который делает вас старшим, становится вашей самой большой ответственностью. Как "делать правильно" или даже "делать просто" часто означает делать неправильно.

Эта статья представляет ментальные модели, которые помогут вам принимать правильные решения и избегать неправильных, которые принял я.

:::tip Для кого это: старшие инженеры, начинающие или присоединяющиеся к стартапам на ранней стадии. Если вы провели 5+ лет в корпорации или Big Tech, это ваше предупреждение.

:::

\

Ментальная модель №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 отличный, и наш инженер мог построить с ним что угодно.

Но "что угодно" требовало времени только для начала. Настройка развертывания, аутентификации и базовых компонентов пользовательского интерфейса означала бесконечную конфигурацию перед написанием единственной функции. Пока мы отлаживали темы Angular Material, конкуренты могут (и будут) использовать Next.js + Vercel, уже подключая пользователей.

Просто сравните это с путем Next.js + Vercel: разверните скелетное приложение с npx create-next-app в первый день, добавьте аутентификацию Clerk и компоненты shadcn/ui, поставляйте реальные функции в первый день. То же назначение, совершенно другое путешествие.

Почему это происходит?

Разница не в качестве фреймворка, а в оптимизации экосистемы. Next.js/React окружен стартапами, поддерживаемыми венчурным капиталом, создающими инструменты для других стартапов:

• UI: shadcn/ui - копировать, вставить, отправить
• Auth: Clerk/Supabase - настроить за минуты
• Deploy: 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 лет с тем, что стоит построить его один раз.

Так что, это не о деньгах, а о приоритетах и альтернативных издержках.

Исключение

По моему мнению, стройте только если вы не можете узнать о пользователях без этого.  Простой пример - когда вам нужно проверить, будут ли пользователи платить за отчеты, сгенерированные ИИ. Постройте самую простую версию, которая доказывает спрос. И все остальное пытается ускользнуть. Да, пропустите инфраструктуру, пропустите "делать правильно", пропустите лучшие практики, которые не поставляют функции, пропустите тесты. Опять же, будьте как можно ленивее в написании кода.

Что я на самом деле использую

• Auth: Clerk (React-native, лучший DX) или Auth0 (ориентированный на B2B, готовый к предприятию)
• Email: Resend (сначала разработчик) или SendGrid (проверенный в боях)
• Analytics: PostHog (бесплатно до масштаба)
• Monitoring: Sentry (непревзойденный для ошибок)
• Hosting: Cloudflare или Vercel (если полностью на Next.js)

Это не одобрения, а мои собственные выборы, оптимизированные для скорости. Я предполагаю, что ваш стек будет отличаться, но этот принцип не изменится.

\

\

Итог

LLMs сделали строительство товаром. Любой младший с Claude может создать ту пользовательскую систему аутентификации, которой вы так гордитесь. Ваша ценность уже не в том, что вы можете построить, А в том, чтобы знать, что не строить.

Лидерство - это способность отделять сигналы от шума. Истинное старшинство означает иметь дисциплину игнорировать 90% того, что вы знаете, и поставлять сегодняшнее решение, а не завтрашнюю архитектуру.