Роль технического сооснователя стартапа кардинально отличается от работы рядового ведущего разработчика в крупной компании. В рамках лекции для инициативы Startup School партнер Y Combinator и бывший CTO Escher Reality Диана Ху делится практическим руководством по созданию продукта от идеи до масштабирования. На примерах таких гигантов, как Stripe, DoorDash и Segment, она объясняет, как расставлять приоритеты на разных стадиях развития бизнеса и почему технический долг на первых порах может стать вашим главным конкурентным преимуществом.
🛠️ Кто такой технический фаундер: отличия от обычного разработчика 1:50
Диана Ху подчеркивает, что технический фаундер — это полноценный партнер в бизнес-путешествии, от которого требуется высочайший уровень вовлеченности. Часто нетехнические основатели совершают ошибку, полагая, что им просто нужен наемный исполнитель, который «напишет приложение». Настоящий технический сооснователь не только руководит разработкой продукта, но и напрямую общается с пользователями.
Распределение ролей CEO и CTO внутри технической команды — нюансированный вопрос. По словам спикера, оно зависит от типа продукта, индустрии и общего состава команды. На ранних этапах деятельность технического основателя во многом напоминает работу ведущего разработчика или главного мейнтейнера open-source проекта. Однако существуют принципиальные отличия, формирующие уникальный круг обязанностей технического фаундера:
- Приходится делать абсолютно все технологические задачи: от фронтенда и бэкенда до devops, ux и администрирования корпоративных аккаунтов Google. В хардверных стартапах нужно одновременно разбираться и в электронике (EagleCAD), и в механике.
- Необходимо развивать склонность к созданию «достаточно хорошей», а не идеальной архитектуры. Крупные компании поощряют идеальный код, но в стартапе приоритетом является скорость действий и принятие решений в условиях неполной информации.
- Нужно научиться жить в хаосе, мириться с техническим долгом, неэффективными процессами и «некрасивым» кодом. По мнению спикера, фраза «это не входит в мои обязанности» для фаундера недопустима.
💡 Стадия идеи: создание работающего прототипа за несколько дней 4:43
На этапе генерации идей (ideating) главная цель команды — как можно быстрее собрать прототип. По мнению Дианы Ху, его единственная задача — продемонстрировать концепт пользователям, при этом продукт даже не обязан полностью функционировать. Пока технический фаундер собирает демо, его партнер-CEO должен формировать список потенциальных клиентов для организации встреч.
Спикер утверждает, что создать прототип за один или несколько дней вполне реально, если использовать существующие специализированные инструменты:
- Для софтверных стартапов: кликабельный макет в Figma или InVision.
- Для инструментов разработчиков (dev tools): скрипт, написанный за пару часов и запускаемый прямо в терминале.
- Для хардверных и глубоких технологических проектов (deep tech): качественные 3D-рендеры, демонстрирующие обещание продукта.
Ху приводит в пример стартап Remora, разрабатывающий устройство для улавливания углекислого газа для грузовиков. Компании хватило качественного 3D-рендеринга, чтобы зажечь интерес клиентов, хотя сам продукт относится к сложнейшей категории хардтека.
Другой показательный кейс — компания Optimizely (выпускники YC W10). Основатели Пит и Дэн изначально подавались в YC с идеей виджета рекомендаций для Twitter, которая полностью провалилась. Дэн, ранее руководивший аналитикой в предвыборной кампании Барака Обамы, вспомнил, как сложно было оптимизировать страницы для сбора пожертвований. Они за пару дней собрали первый визуальный редактор для A/B-тестирования, представлявший собой обычный JavaScript-файл на сервере S3. Основатели открывали консоль Chrome (Cmd+Opt+J) и вручную запускали тест. Никто, кроме самих авторов, не мог этим пользоваться, но маркетологи пришли в восторг от самой концепции.
Собственный стартап Дианы Ху Escher Reality создал прототип алгоритмов компьютерного зрения для смартфонов за несколько недель. Это было намного эффективнее для продаж, чем «объяснение на пальцах». К основным ошибкам на этой стадии спикер относит избыточное усложнение (overbuilding), страх показать «сырой» продукт пользователям и чрезмерную привязанность к идее, мешающую вовремя признать ее нежизнеспособность.
🚀 Разработка MVP: скорость запуска и отказ от раннего найма 8:33
Когда прототип подтвердил интерес рынка, стартап переходит к сборке MVP (минимально жизнеспособного продукта). По оценке Ху, для софтверных компаний нормальный срок разработки MVP составляет от нескольких дней до пары недель. Главная цель — получить от пользователей твердое обязательство использовать продукт, а в идеале — заставить их заплатить.
Диана Ху предостерегает фаундеров от популярной ошибки — найма сторонних инженеров сразу после успешного демо прототипа. По ее мнению, на ранней стадии наем только замедлит команду по следующим причинам:
- Поиск хорошего инженера на рынке среди незнакомых людей занимает больше месяца. В условиях хаоса и неопределенности адаптировать новичков крайне сложно.
- Самое опасное: основатели теряют глубокое понимание своего продукта. Если код пишет наемный сотрудник, фаундеры упускают «золотые крупицы» инсайтов об архитектуре и поведении технологий, которые могли бы определить эволюцию бизнеса.
Примером правильного фокуса служит история создания Justin.tv (будущего Twitch). На старте над MVP работали всего четыре человека, включая трех сильных технических сооснователей: Джастин, Эммет и Кайл. Они распределили задачи: Кайл бесстрашно взял на себя сложнейшую проблему стриминга видео, Эммет занимался базами данных, а Джастин — веб-частью. Это позволило запуститься своими силами. Лишь после запуска они наняли разработчиков, причем искали не по резюме, а выбирали талантливых «аутсайдеров», которых проглядел Google — и те за три месяца полностью переписали видеоплатформу.
⚙️ Технические принципы MVP: «немасштабируемые дела» и метод 90/10 11:33
При создании MVP Ху рекомендует опираться на два фундаментальных принципа YC.
Принцип 1: Делайте вещи, которые не масштабируются (Do things that don't scale). Спикер советует находить хитрые хаки ради быстрого запуска. Например, стоит избегать автоматической регистрации и онбординга пользователей (self-onboarding), так как это требует кучи серверной логики. Вместо этого лучше использовать ручной онбординг: фаундеры сами вносят пользователей в базу данных вручную. Сюда же относится сумасшедшая ручная техподдержка силами основателей. Классический пример — Stripe. При запуске у них был красивый API для приема платежей, но на бэкенде фаундеры вручную обрабатывали каждый запрос и лично заполняли банковские формы, чтобы проводить транзакции.
Принцип 2: Решение 90/10. Этот термин ввел партнер YC Пол Букхайт (создатель Gmail). Суть в том, чтобы отложить максимум фич на период после релиза. Спикер уточняет: это не значит делать продукт с багами, код должен быть достаточно хорошим, но продукт нужно жестко ограничить. Сузить проблему можно по типу данных, поддерживаемым устройствам, географии или функционалу. По мнению Дианы Ху, в этом кроется суперсила стартапа: крупные компании не могут позволить себе такие ограничения из-за юристов, финансистов и комплаенса.
Яркой иллюстрацией принципа 90/10 является запуск DoorDash (изначально Palo Alto Delivery). Проект собрали за один день. На сайте были просто статичные HTML/CSS и PDF-файлы меню ресторанов. Там был указан личный мобильный номер одного из основателей. Никакого бэкенда не существовало: вместо него использовались Google Forms и Google Docs для координации заказов. Для отслеживания курьеров и времени доставки не писали никакого софта — основатели просто использовали стандартное приложение Find My Friends на iPhone. Так как создатели были студентами Стэнфорда, они жестко ограничили геозону Пало-Альто. По мнению спикера, именно этот фокус помог им идеально выстроить юнит-экономику в пригороде, что впоследствии позволило победить конкурентов (таких как GrubHub), выбравших сложные мегаполисы.
💻 Выбор технологического стека: скорость итераций против «инженерного снобизма» 15:04
При выборе стека Диана Ху советует балансировать между спецификой продукта и личной экспертизой, чтобы шипить код максимально быстро. Нельзя выбирать новый язык программирования просто ради того, чтобы изучить его в рамках стартапа. Спикер рекомендует активно использовать готовые сторонние API и фреймворки: Auth0 для авторизации, Stripe для платежей, React Native для кроссплатформенности, AWS/GCP для инфраструктуры, Webflow для лендингов, AWS Lambda или Firebase для серверной логики. В прошлом стартапы сжигали все деньги до запуска, закупая собственное «железо», сегодня же собирать MVP с нуля — глупость.
На возражения некоторых CTO о том, что сторонние API обходятся дорого и не масштабируются, Ху отвечает известным мемом «Mid-wit» (средний ум), который популяризировал Шон Ванг (swyx). Мем описывает три уровня инженеров:
- «Новичок» (Noob) не знает сложных концепций, берет PHP или JavaScript и быстро собирает работающую «игрушку».
- «Средний инженер» (Mid-wit) смеется над новичком, заявляя, что PHP не масштабируется. Он пытается копировать процессы Google и внедряет тяжелую инфраструктуру: Kafka, Linkerd, ROS, Prometheus, Kubernetes, Envoy и сотни микросервисов. По замечанию Ху, именно на этом этапе средний стартап обычно умирает, так и не запустившись.
- «Мастер-Джедай» (Jedi Master) смотрит на проблему шире. Его решение внешне выглядит в точности как у новичка — он тоже берет PHP и JavaScript, но делает это осознанно, ради максимальной скорости итераций.
По мнению спикера, если стартап взлетает и получает пользователей, любые проблемы со стеком можно решить деньгами и ресурсами. Facebook был написан Марком Цукербергом на PHP просто потому, что он его хорошо знал. Когда масштаб стал критическим, инженеры Facebook решили эту проблему на уровне «джедаев» — написали кастомный транспайлер HipHop для компиляции PHP в C++.
Другой пример — компания WayUp (YC 2015), платформа для найма студентов. Их CTO Джей-Джей (JJ) был самоучкой. В 2015 году он выбрал для бэкенда Python и Django, хотя в трендах Google тогда в 10 раз популярнее был Ruby on Rails. Простой стек (PostgreSQL, Python, Heroku) отлично сработал и помог компании быстро расти. Диана Ху резюмирует: единственные технологические решения, которые имеют значение — это те, которые напрямую связаны с вашими обещаниями клиенту. В ее стартапе Escher Reality код переписывали с нуля несколько раз, но неизменным оставалось обещание клиентам на уровне API для движка Unity — его трогать было нельзя.
📊 Стадия запуска: аналитика, непрерывные релизы и Pivot 19:42
После запуска MVP цель стартапа — итерировать продукт для достижения соответствия рынку (Product-Market Fit, PMF). Для этого Ху советует сочетать два типа данных: жесткие (hard data — метрики) и мягкие (soft data — интервью). Метрики отслеживают через простые панели вроде Google Analytics, Amplitude или Mixpanel. Усложнять стек системами Logstash или Prometheus на этом этапе не нужно. Мягкие данные получают, продолжая непрерывно общаться с пользователями, чтобы понять причины оттока (churn).
Кейс компании WePay отлично иллюстрирует этот подход. Они запускались как B2C-платежка (аналог Venmo), но продукт «не взлетал». С помощью аналитики фаундеры заметили, что большинство фич (например, обмен сообщениями) никому не нужны, а главным клиентом платформы внезапно стал благотворительный сервис GoFundMe. Поговорив с представителями GoFundMe, основатели поняли, что тем не нужен пользовательский интерфейс WePay — им нужен чистый API для интеграции платежей. Компания совершила пивот (pivot) в сторону API. Первая версия не имела даже технической документации, её внедряли вручную, делая вещи, которые не масштабируются. Именно эта API-версия привела WePay к успеху.
Второй принцип стадии запуска — непрерывные релизы (continuously launch). Компания Segment начинала с софта для классных комнат, идея полностью провалилась. Тогда они вырезали кусок своего бэкенда и превратили его в самостоятельный продукт для аналитики. Свой первый пост на Hacker News они опубликовали в декабре 2012 года и получили огромный отклик. Поняв, что нащупали PMF, они начали выпускать обновления каждую неделю — сделали 5 крупных релизов за месяц, добавляя интеграции по запросу пользователей (сначала были только Google Analytics, Mixpanel и Intercom, затем добавили Node, PHP, WordPress). В итоге Segment вырос в «единорога» и был продан компании Twilio за 3,2 млрд долларов.
📈 Технический долг и трансформация роли CTO до и после PMF 22:46
На этапе движения к PMF техническому директору важно соблюдать баланс между созданием новых фич и исправлением багов. По мнению Дианы Ху, технический долг на этой стадии — абсолютно нормальное явление, и фаундер должен научиться спокойно относиться к тому, что его код «горит». Ошибки в коде редко убивают стартап, если продукт действительно нужен людям.
Спикер приводит в пример феноменальный запуск Pokemon Go в 2016 году. В игру неделями никто не мог нормально зайти из-за падения серверов, но это не помешало проекту заработать миллиард долларов выручки за прошлый год. С технологической точки зрения там возникла критическая перегрузка: балансировщик Google Cloud направлял трафик на nginx для TCP/HTTP-терминации, откуда запросы шли на серверные приложения (AFE, Application Front End). Из-за того, что сессии пользователей не разрывались вовремя на уровне nginx, а клиенты постоянно слали повторные запросы (retries), возник эффект непрерывной DDoS-атаки. За первый месяц Pokemon Go достиг объема активной аудитории Twitter, к которому тот шел 10 лет. Серверы ложились, но пользователи все равно возвращались, что доказывает приоритет ценности продукта над стабильностью архитектуры на старте.
Главные ошибки CTO после запуска, по оценке спикера:
- Попытки строить инфраструктуру «как в Google» до достижения PMF.
- Уход в глухую оборону: фокус исключительно на рефакторинге кода вместо добавления фич, ведущих к PMF.
- Изоляция от клиентов. По мнению Ху, CTO обязан лично участвовать в разборе фидбека, а не просто закрываться в редакторе кода.
- Игнорирование технологий роста (growth tech) — инженеры должны работать в связке с отделом продаж и маркетинга ради вирусных хаков.
После достижения Product-Market Fit роль технического фаундера кардинально меняется. Только на этом этапе можно «надеть большие инженерные штаны» и заняться масштабным рефакторингом. Продукт будет ломаться от наплыва пользователей, и это правильный момент для перестройки архитектуры (как это было с серверами Pokemon Go).
Также меняется вовлеченность фаундера в написание кода из-за операционных издержек (communication overhead) при росте команды:
- Когда в команде от 2 до 5 инженеров, CTO пишет код примерно 70% времени.
- При росте команды до 5–10 человек на кодинг остается менее 50% времени.
- Когда инженеров становится больше 10, времени на написание кода практически не остается. Фаундеру приходится выбирать: оставаться в роли технического архитектора или полностью уходить в менеджмент и управление людьми (VP of Engineering).
