Как я отговорил клиента строить цифровой авианосец за 2 миллиона (и почему он меня сначала ненавидел)
Это история не о том, что мы сделали. А о том, что мы не сделали — и что из этого вышло.
Заказчик пришел ко мне с готовым ТЗ, бюджетом и мечтой. Я изучил всё это и сказал: «Ваше приложение никому не нужно. Давайте не будем его делать». В тот момент в его глазах читалась настоящая ненависть. Через полгода он вернулся — чтобы поручить мне развитие того, что реально сработало.
Часть 1: «Безупречное» ТЗ, или Почему ваш стартап — не Яндекс.Карты
Клиент пришёл с глубоким пониманием ниши (беженцы из стран Африки в Израиле) и солидным бюджетом. Его ошибка была не в идее, а в фатальном желании построить "готовый к масштабу" продукт с первого дня. Его ТЗ было техническим заданием не на MVP, а на полноценную компанию с первого релиза.
Вот на чём он настаивал с самого начала:
- «Умная» карта с оптимизацией маршрутов для 5 заказов одновременно. Проблема в том, что на старте 10 заказов в день была бы фантастической удачей. Он хотел алгоритмы Яндекс.Карт для велосипедиста, который катается по двору. Сложность и стоимость разработки — на порядок выше, а польза на старте — нулевая.
- Сложная система ролей: клиент-курьер-админ. Особенная фишка: курьер должен был иметь возможность покупать товары в том же приложении. Это кардинально усложняло логику, безопасность и интерфейсы. Всё — ради гипотетической ситуации, когда один-единственный курьер на всём стартапе захочет что-то купить. Он строил архитектуру Amazon для ларька, который ещё даже не открылся.
- Многоязычность с RTL (поддержкой письма справа-налево) с первого дня. Редкие африканские языки — правильно, это ядро ЦА. Но иврит и арабский («на перспективу») тут же втягивали в дорогую и сложную вёрстку RTL, откладывая запуск на месяцы ради аудиторий, которые, по его же словам, покупать у него не собирались.
- Оплата только наличными — здесь клиент был трезв, понимая свою аудиторию. Но в дорожной карте уже значилась «онлайн-оплата на втором этапе», что добавляло психологического давления: «Всё равно потом переделывать».
Его логика (классическая): «Если делать — то делать сразу хорошо, на годы вперёд. Чтобы потом не переделывать». Мой диагноз (основанный на опыте): «Вы готовитесь переделывать и масштабировать то, что, с высокой вероятностью, никогда не заработает в желаемом виде. Давайте сначала проверим самую рискованную гипотезу (а будут ли вообще заказы?) на самой простой, дешевой и быстрой версии. Потому что если гипотеза не верна — вам не понадобится ни RTL, ни оптимизация маршрутов».
Главная ошибка: Он хотел инвестировать время и деньги в масштабирование и оптимизацию процесса, который еще не существовал, в удовлетворение потребностей пользователей (курьеров, израильтян), которых у него еще не было. Это классический пример цифрового риска, о котором я писал в Цифровой Перл-Харбор: Как слепая атака платформы может потопить бизнес.
Если вы узнаете в этом своё ТЗ — остановитесь и выдохните. Вы на правильном пути, читая эту статью! Следующий раздел — о том, как я это аргументировал и что предложил вместо этого.
Часть 2: Мой вердикт и альтернатива — «Рыболовный траулер» вместо «Авианосца»
Мой ответ был жёстким, но конструктивным. Я не сказал: «Ваша идея — бред». Я сказал: «Вы хотите построить авианосец, чтобы проверить, есть ли рыба в этом районе океана. Давайте для начала спустим на воду недорогой рыболовный траулер».
Его реакция была предсказуемой: сопротивление и недоверие. Ему казалось, что я не верю в его экспертность по ЦА и намеренно «урезаею» его идеальный продукт. Начались споры за спором.
Но я стояли на своём, аргументируя каждый пункт не мнением, а экономикой разработки и логикой проверки гипотез. Вот мой разбор его ТЗ и альтернатива, за которую я бился:
1. По «умной» карте и маршрутам для 5 заказов:
- Моя позиция: «Зачем строить собственный алгоритм оптимизации маршрутов месяц, вкладывая серьезные деньги, если на старте у вас нет даже 5 одновременных заказов? Давайте решим задачу «доставить из точки А в точку Б» здесь и сейчас».
- Мое предложение (и что мы в итоге сделали): Встроили Google Maps со стандартным виджетом. Он показывал местоположение курьера и точку доставки. Одна кнопка вела в штатный навигатор (Google Maps), который и так оптимально строил маршрут. Итог: Функциональность «трекинг + навигация» была готова за пару дней, а не за месяц. Не было «оптимизации 5 точек», зато была работающая доставка с первого дня.
2. По системе ролей и «гибридному» пользователю:
- Моя позиция: «Вы закладываете в архитектуру поддержку «гибридного» пользователя (курьер, который может ещё и покупать), что грозит хаосом в логике, интерфейсе и часами неоправданной сложной разработки. И всё это — ради сценария, который на старте маловероятен. Давайте разделим ответственность четко и навсегда».
- Мое предложение (и итоговая архитектура): Мы внедрили жёсткое, но простое разделение на три независимые роли, каждая со своим интерфейсом и целью:
- Клиентское приложение: Только товары, корзина, история заказов. Приложение курьера: Только свежие и исполненные заказы + карта одного заказа, который он взял в работу. Веб-панель администратора: Полный контроль над товарами, заказами, курьерами и аналитикой.
- Результат: Мы исключили «тёмную материю» гибридных сценариев. Разработка пошла в 3 раза быстрее, логика стала кристально чистой.
3. По многоязычности и RTL:
- Его требование: африканские языки, иврит, арабский (с RTL) — сразу, на старте.
- Моя позиция: «Ваша реальная ЦА — африканцы. Сфокусируйтесь на ней. Иврит и арабский с их RTL — это отдельный, сложный и дорогой проект, который отложит запуск на месяцы. Давайте сделаем это версией 2.0, когда у вас будут первые 100 платящих клиентов».
- Мое предложение (и итоговый компромисс): Только несколько африканских языков и английский в первой версии. Английский — для администратора, чтобы он мог управлять системой. RTL и дополнительные языки — вынесены за скобки первого релиза. Это сократило сроки в 2 раза.
В итоге, после долгих споров, он согласился с моими доводами. Не потому что сдался, а потому что логика и цифры оказались сильнее эмоций.
Суть моего подхода: Минимизировать время выхода на рынок (Time to Market) и стоимость провала (Cost of Failure). Последнее напрямую связано с юнит-экономикой. Если вы еще не считали, как внешние риски съедают вашу маржу, начните с основ — Озоновское обдиралово: закрывать лавочку или воевать умением?.
Я предложил не «урезанную» версию его мечты, а совершенно другой продукт — инструмент для проверки единственной рисковой гипотезы: «Готовы ли беженцы из Эфиопии заказывать этот товар через мобильное приложение?»
Это и был «рыболовный траулер»: дешёвый, быстрый, позволяющий проверить воду. Если рыба есть — можно достраивать «авианосец» уже на реальных данных.
Часть 3: Результат, или Что вышло из того, что мы «не сделали»
Итак, мы запустили «траулер» — упрощённую, но работающую систему — вместо «авианосца».
Что это дало клиенту:
- Запуск не за 6 месяцев, а за 6 недель. Мы вышли на рынок в 5 раз быстрее, пока конкуренты все еще проектировали «идеальную» архитектуру.
- Бюджет не 2+ миллиона, а в разы меньше. Мы сократили стоимость провала до минимальной. Если бы гипотеза не сработала — он бы потерял не состояние, а сумму, сопоставимую с рекламной кампанией.
- Не данные из воздуха, а реальная статистика. Через месяц у него были не красивые скриншоты Figma, а цифры: конверсия в заказы, средний чек, популярные товары, часы пиковой активности. Данные, на которые можно опереться, принимая решения о масштабировании.
- Не «гибридный хаос», а отлаженный процесс. Разделение ролей и простые интерфейсы позволили с первого дня работать без сбоев. Курьеры не путались в кнопках, админ управлял всем из одной панели.
А что же с его «мечтой» — RTL, арабским, оптимизацией пяти заказов?Они не исчезли. Они переместились из колонки «неизвестные затраты на непроверенную гипотезу» в колонку «конкретные задачи для второй итерации, основанные на данных».
Именно тогда, через полгода, он вернулся. С новым, конкретным и обоснованным ТЗ:
- «Нужна интеграция с израильской платёжной системой для 15% клиентов, которые спрашивали про онлайн-оплату».
- «Добавьте арабский интерфейс: у нас есть постоянные клиенты из этой группы».
- «Давайте улучшим логистику: теперь у нас стабильно 20+ заказов в день, и вручную маршруты строить тяжело».
Мы перешли от слепого строительства к итеративному развитию на основе обратной связи. От отношений «заказчик-исполнитель» к партнерству «проводник-предприниматель».
Заключение: Урок, который стоит дороже 2 миллионов
Эта история не о том, как я спас кого-то от провала. Она о двух типах подрядчиков и двух типах мышления:
- Исполнитель скажет: «Как скажете. 2 миллиона? Без проблем. Сделаем всё, что в ТЗ». Его KPI — получить оплату по договору.
- Проводник (как мы) скажет: «Стоп. Давайте сначала убедимся, что это вообще нужно. Я не позволю вам потратить 2 миллиона впустую, даже если вы этого хотите». Его KPI — успех вашего бизнеса.
Если вы заказчик, задайте себе вопрос перед следующим проектом:
Проводник — это не тот, кто всегда говорит «Чего изволите?». Это тот, кто имеет смелость и экспертизу сказать «нет», «не так» или «не сейчас» — и аргументировать почему. В долгосрочной перспективе это окупается в десятки раз.
«Я нанимаю "рабочие руки", которые построят мне замок из песка по моему чертежу? Или "мозги и опыт", которые остановят меня у обрыва и помогут построить Небоскреб на Манхэттене?»
Если эта логика вам откликается и хотите разобраться со своей ситуацией — добро пожаловать в мой телеграм-канал.
Там без воды разбираю реальные кейсы, ошибки стартапов и стратегии, которые реально работают.