На собственном опыте я узнал, что партнерство с людьми без технического бэкграунда, которые хотят построить стартап, не всегда оказывается тем, что ожидаешь. У этих людей обычно есть идея, экспертиза в целевой области, деньги или все сразу – и видение, которое они считают прорывным. Но нет продукта.
Я проходил через это несколько раз. В такой конфигурации, несмотря на кажущуюся эффективность связки технарь-идея-инвестор – ни разу ничего не запустилось. Всегда находится что-то, из-за чего ваш ко-фаундер – или единственный фаундер и инвестор – не делает свою часть и не пробует свой продукт на реальных людях. Даже если от этого зависит успех всего предприятия и собственный капитал, который буквально каждый день сгорает в процессе.
В противовес – в соло, за последние несколько лет я сделал и запустил несколько продуктов и сервисов – большинство из них умерло после пользовательского фидбэка и из-за недостатка маркетинговых навыков с моей стороны. Но они хотя бы пытались дойти до рынка.
В отличие от тех, что делались с партнерами и командами.
И на это есть несколько причин – или, как я назвал это в заголовке, паттернов.
1. Это техническая проблема
Почему мы не запускаемся? У нас техническая проблема.
Да, прототип готов, и мы его протестировали, и идея работает.
Да, мы построили вокруг него MVP.
Да, у нас есть Продукт, который реальные люди могут пощупать и попробовать – чтобы мы получили фидбэк, скорректировались или свернулись пока не поздно.
Но– продукт не готов, потому что есть техническая проблема.
Понимаешь, поиск работает в 90% случаев – и не работает совсем в очень специфичном случае. Мы не готовы, это техническая проблема.
Понимаешь, в онбординге три шага – а пользователю понадобится пять. И это техническая проблема.
Продукт покрывает 80% того, что может понадобиться пользователю; мы даже не знаем, что в оставшихся 20% – но нам нужно с этим разобраться, прежде чем кому-то это показывать.
Иначе – продуктукапут.Самые первые пользователи, которым мы покажем эту неотшлифованную версию MVP, расскажутвсем остальнымв мире, и нам конец.
Как можно догадаться, причина часто не техническая.
Партнер на другой стороне проекта – тоже человек, и он может быть не уверен в себе, бояться показать что-то неидеальное. Сказать «продукт не готов» проще, чем «я не готов».
Если ты равноправный партнер, есть о чем поговорить. Найти компромисс.
Хорошо, еще одна итерация – и запускаемся.
Но если ты подрядчик, работающий на инвестора – твое мнение, по сути, не учитывается. Ты просто пишешь код.
Тому, у кого видение, не нужны советы от того, кто просто делает штуки. Стив Джобс ведь, когда делал iPhone, ни у кого совета не спрашивал, правильно?
Так что мы не застряли. Это техническая проблема.
2. Цикл «еще одна фича»
Кто не любит фичи? Все любят фичи. Особенно когда ты тот, кто строит. Когда процесс – все, а результат по agile. Я такой же.
Но в какой-то момент нужен фидбэк. Настоящий, от живых людей. И каждый отложенный день – это полет вслепую.
Еще одна фича – и запускаемся. Хорошо, еще одна. И еще одна после этой.
И вот у нас уже составлены целые списки важных изменений.
Имплементируешь, переделываешь, редизайнишь. Через неделю мы на том же месте – но зато теперь у нас есть крутая анимация загрузки и хаптик.
Только это все еще никто не видел.
И вот вещь, которая проходит мимо, пока полируешь: каждая такая "еще одна штука" – уже не улучшение, это новая версия. Потом еще одна. И так мы ходим по кругу.
А outreach, который должен был быть сделан еще до того, как ты закончил core user flow – так и не был начат.
3. Я в курсе про Codex
Все знают про AI-инструменты, которые изменили индустрию. Codex, Claude Code – это на слуху у каждого. Ваш нетехнический кофаундер за этим всем следит и читает твиттер про вайб-кодинг.
Кто-то в твиттере выкатил стартап за выходные.
Почему мы не можем так же? Почему у нас так долго? Есть же ИИ, он пишет за тебя код, верно?
И конечно – доля истины тут имеется. То, что происходит со скоростью разработки благодаря AI – временами действительно поразительно. Не использовать эти инструменты как следует – значит терять время и деньги.
Но знать, что инструмент существует, и знать,чтос его помощью можно сделатьи как– это разные вещи. Микро-SaaS твоего друга со Stripe-оплатой, собран за выходные с Claude Code? Супер. Теперь попробуй связать десять-пятнадцать сервисов, соркестрировать их, развернуть на инфраструктуре посложнее, чем VPS на Hetzner с парой Docker-контейнеров.
И самое важное – попробуй заранее знать, что нужна именно такая архитектура. Тут промпт-инжиниринг не поможет. Это годы построения систем и экспериментов, чтобы понять, как они должны работать и почему они ломаются.
4. Ложная компетентность
Вы видели эти посты. Кто-то провел выходные общаясь с ChatGPT и раскрыл проблему в теории чисел или понял, где физика ошибалась последние сто лет. По крайней мере, им так кажется. В стартапе проблема случается ровно та же, просто в масштабе одного продукта и не с кем-то в интернете, а буквально с твоим партнером по проекту.
Это можно сделать, и очень просто. ChatGPT рассказал мне как.
MVP есть, но он не идеален. А когда у вас в голове есть картина продукта – «не идеален» значит «не готов».
Хорошая новость – в 2026 году, чтобы понять, что что-то не так, не нужно понимать код. И не нужно быть разработчиком, чтобы спросить ChatGPT, как это починить.
И вот ты начинаешь спрашивать. Аккуратно. Методично. Ты описываешь продукт. Ты рассказываешь, что с ним не так. Ты спрашиваешь, почему он сделан так, а не иначе. Подвергаешь сомнению каждый ответ. Копаешь глубже. Задаешь вопросы, об которые даже senior-инженер бы запнулся. Доходишь туда, где никто из твоей команды, по-видимому, не был.
Оказывается, мы все делали неправильно. Все это время.
Через три часа ты выходишь с Тем Самым Решением. Тем, которое наконец-то все исправит.
Технические проблемы, которые блокировали запуск – решены. Недостающие фичи – продуманы. Сроки, которые казались слишком долгими – ChatGPT объяснил, как это сделать за пару часов.
И вот вы на созвоне. И вам презентуют новую архитектуру – не очень понимая, что это слово означает в разработке софта. Теперь это нужно просто построить.
Кстати – вот лог чата. Выведенный план выглядит как настоящий, просто не очень конкретный – разобраться ваша задача, вы же программисты, в конце концов. Но направление понятное: весь наш подход был неправильный, и ChatGPT это только что доказал.
Работа теперь – читать между строк трехчасового разговора нетехнического человека с AI-чатботом, который никогда не говорит «не знаю».
Здесь можно попробовать спорить. Но спор это будет уже не с кофаундером, а с ChatGPT – через него.
Или можно просто забить и делать, что они хотят. Пока не закончатся деньги. И сам проект не пойдет ко дну.
Совсем просто подрядчику – можно доделать и пойти дальше.
В описанных случаях я упоминаю ИИ в основном как причину задержек и инструмент давления. Но на самом деле то, что он позволяет сейчас делать соло-билдеру или команде с разумным экспертом в конкретном домене, которому нужен продукт – потрясающе.
Для тех, кому будет интересно – я сделал короткий ролик с англоязычной версией этой заметки и с демо подхода, который можно использовать для быстрой сборки прототипов.
Надеюсь, эти мои наблюдения найдут кого-то и помогут лучше понять причины, по которым запуск проекта тормозит или постоянно откладывается. А если вы совершаете эти ошибки даже в соло – помните, вы не одни.
