Знакомьтесь, Макс. Умный парень, фаундер. У него есть накопления, горящие глаза и идея, которая не даёт спать: сделать “Airbnb для строительной техники”. Чтобы любой прораб мог в два клика арендовать экскаватор, а владелец бульдозера — видеть, где его техника и сколько она заработала.

Макс приходит к IT-подрядчику с одним главным вопросом, который зудит у каждого на старте:

— Ребята, идея пушка. Сколько стоит это сделать?

Менеджер, почти без уточнений, отвечает бодро и уверенно:

— Ну, если брать по классике… примерно $20,000 и три-четыре месяца работы.

Сделка состоялась. Шампанское открыто. Все улыбаются.

Но давайте заглянем в головы участников этой сцены:

• Менеджер думает о квартальной премии за закрытую сделку.
• Техлид, которому только что скинули задачу, в ужасе думает, что придётся ужать: тесты, админку, мониторинг, безопасность, чтобы вложиться в “три-четыре месяца”.
• Макс уже видит релиз и думает, как через 3 месяца будет заселять экскаваторы в свои “цифровые гаражи”.

В этот момент Макс подписал смертный приговор своему стартапу.
Просто узнает он об этом только через восемь месяцев, когда бюджет сгорит, приложение начнёт падать при попытке загрузить фото, а разработчики разведут руками: “Ну, вы же не сказали, что нужна геолокация в реальном времени, это уже допработы…”.

Иллюзия товара

Макс попал в ловушку восприятия. Ему кажется, что он покупает Товар — коробку с готовым софтом, как новый iPhone. Ты платишь деньги — тебе дают коробку. Всё предсказуемо.

В таких ситуациях почти всегда продаётся одно и то же — иллюзия контроля. Потому что в IT разработка уникального продукта — это не покупка товара. Это строительство завода, который будет производить ценность. И когда Макс просит назвать цену завода, не показав чертежи станков и схему коммуникаций, любая названная цифра — это фикция.

Немного отрезвляющей статистики:
Согласно данным McKinsey, крупные IT-проекты в среднем превышают бюджет на 45%, а сроки — на 7%, при этом доставляя на 56% меньше ценности, чем планировалось.
Корень зла — требования, которые “додумывали по дороге”.

Когда вы приходите за уникальным продуктом, вы не покупаете квартиру в мегаполисе. Вы выходите в чистое поле и начинаете строить город.

Недвижимость: Квартира в городе vs Дом в чистом поле

Проблема большинства фаундеров (и Макса тоже) редко в деньгах или идее. Проблема в другом: они хотят жить в собственном особняке с бассейном, но мыслят категориями ипотечного заемщика, покупающего “двушку” в панельке.

Давайте честно разберёмся, что вы на самом деле покупаете, когда приходите в IT.

Вариант А: Квартира в панельке

(Типовое решение / CMS / SaaS)

Если Максу нужен простой интернет-магазин футболок, ему не нужна разработка. Ему нужна Tilda, Shopify или готовый шаблон на популярной CMS.

Это квартира в городе:

• Инфраструктура: уже есть. Вода течёт, свет горит, мусор вывозят, ЖЭК работает.
• Цена: фиксированная и относительно низкая.
• Свобода: минимальная. Вы живёте по правилам дома. Хотите снести несущую стену, чтобы объединить кухню с залом? Нельзя. Хотите прорубить окно в потолке? Запрещено.

Зато можно заехать быстро и без головной боли.

Вариант Б: Дом в чистом поле

(Кастомная разработка / Стартап)

“Airbnb для экскаваторов” — это не типовой магазин. Здесь сложная логика бронирования, страховка, заморозка депозитов, GPS-трекинг, роли “Заказчик” / “Исполнитель” / “Админ”. CMS “из коробки” решает это только костылями и компромиссами. И с потолком по сложности, который диктует платформа.

Макс строит дом в чистом поле. И вот здесь реальность начинает выставлять счета.

Макс спрашивает:

— “Сколько стоит дом?”

А мы, как инженеры, смотрим на поле и видим не дом, а пустоту:

• Здесь нет электричества — нужно строить собственную подстанцию (Backend).
• Здесь нет труб — нужно бурить скважину и тянуть канализацию (API и интеграции).
• Здесь нет дорог и охраны — нужно прокладывать асфальт и ставить забор (DevOps и безопасность).

Пока нет проекта, цена выглядит как диапазон: меняется глубина фундамента, меняется смета.

Макс платит не только за “кирпичи” — интерфейс, который он видит на экране. Он платит за создание “автономного государства” с нуля — роли и права, данные, правила расчётов, журнал событий, мониторинг, аварийные сценарии.

Требовать от разработчика цену “как за квартиру”, заказывая строительство автономного объекта с собственной инфраструктурой, — это прямой путь к недострою.

Сравнительная таблица: что вы на самом деле строите

Вывод

Если вам нужна уникальная бизнес-логика, забудьте про “фикс-прайс за квадратный метр”. Вы играете на рынке капитального строительства, где смета рождается из проекта.

В типовом софте цена фиксируется заранее. В кастоме сначала фиксируется проектирование, потом — смета.

И вот здесь возникает следующий опасный миф: “Окей, дом строим. Но ведь кирпичи уже есть. Просто возьмите готовые и сложите”. К сожалению, так это не работает.

Дальше мы расскажем, почему “просто сложить из готовых модулей” превращается в напильник и костыли.

Кирпичи: почему “конструктор” быстро превращается в напильник.

После аналогии с домом Макс обычно не сдаётся и достаёт свой главный козырь:

— Хорошо, мы строим дом. Но ведь кирпичи-то уже изобретены! Есть готовые модули, библиотеки, фреймворки. Зачем вы усложняете? Просто возьмите готовое и сложите вместе.

Это самый популярный миф в IT, который сжигает бюджеты тихо и системно: “Всё уже написано до нас”.

Давайте вернёмся на стройку.

Представьте, что весь мировой IT-рынок — это гигантский завод по производству прямоугольных кирпичей.

Это стандартные решения: стандартная корзина, стандартная авторизация, стандартный чат поддержки. Они дешевые, проверенные и лежат на каждом складе.

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

А бизнес Макса (“Airbnb для экскаваторов”) — это не типовая коробка.

Его бизнес-модель требует треугольных кирпичей.

Ему нужна не просто “корзина”, а сложная система почасового биллинга с учётом простоя техники, коэффициентов погоды, рейтинга водителя и штрафов за срыв брони.

И здесь у нас есть два пути.

Путь 1. “Костыли и изолента”

(Иллюзия экономии на типовых решениях)

Мы берём стандартный прямоугольный кирпич — готовый модуль CMS — и начинаем его пилить, чтобы он стал треугольным.

Результат?

Это работает. Но криво.

Вокруг куча пыли — лишний код. Кирпич теряет прочность — появляются баги. А стена из таких обрезков шатается при первой же попытке нагрузить её реальным трафиком.

На старте это всегда выглядит как победа: быстро, дешево, “мы сэкономили”.

Но любой ремонт такой стены стоит в три раза дороже. Потому что никто, кроме автора этого “распила” (а он уже мог покинуть команду), не знает, на чём всё вообще держится.

Это называется технический долг — проценты, которые вы начинаете платить с каждым новым релизом. И он накапливается с первого дня.

Путь 2. “Построить производственную линию”

(Путь Custom Development)

Кастомная разработка — это не укладка готовых кирпичей.

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

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

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

В первом же случае вам придётся сносить дом. Потому что “пиленые” кирпичи не выдержат нагрузки.

Вывод

Если ваш стартап уникален (а иначе зачем вы его делаете?), стандартные детали вам не подойдут.

Вы платите не за кладку стены. Вы платите за инженерию, которая позволяет эту стену вообще создать.

И вот здесь Макс задаёт следующий, самый важный вопрос:

— Хорошо. А сколько стоит построить этот завод?

И здесь мы подходим к главному водоразделу. Наивное ожидание — получить цену завода, глядя на эскиз детали. Профессионал сначала спроектирует завод, чтобы понять его стоимость.

Для этого нужна не примерная цена, нарисованная на салфетке за пять минут, а точный инженерный промпт мышления.

Промпт для инженера: Детализация как валюта

Он уже понял, что ему нужен не типовой кирпич, а завод для производства кастомных блоков. И он задает единственный логичный вопрос: “Сколько стоит завод?” Но правильный вопрос звучит иначе. Почему мы не можем назвать цифру прямо сейчас?

Давайте проведем аналогию, понятную любому современному фаундеру. Представьте, что вы открыли Midjourney или SORA.

Если вы напишете промпт: “Сделай мне красиво” или “Нарисуй машину” — нейросеть выдаст вам результат “по умолчанию” — местами странный, местами мимо задачи. Машину с пятью колесами, тремя рулями и дверью на крыше.

Чтобы получить шедевр, вы должны написать промпт на две страницы: стиль, освещение, детализация, контекст, ограничения.

В разработке ТЗ и Дизайн — это ваш инженерный промпт. Чем детальнее промпт, тем меньше сюрпризов будет при разработке.

Туман войны и пазлы

Во многих стартапах/проектах (как и в стратегиях типа StarCraft) действует “Туман войны”.

В начале пути наш Макс видит только себя (точку старта) или своё ТЗ, которое он считает идеальным. Весь остальной ландшафт скрыт. Там, в темноте, может оказаться: ровная дорога, крутые горные холмы или болото, где утонет вся техника.

Оценка проекта без проектирования — это попытка собрать пазл на 10 000 элементов:

1. Без картинки на коробке.
2. В темной комнате.
3. На ощупь.

Сначала мы видим “кашу”. Потом, в процессе Discovery, мы находим угол сцены, потом ключевой экран, потом рамку. Чем больше элементов мы открываем (проектируем), тем больше сжимается туман войны.

Математика dZENcode: Никакой магии

Мы не гадаем на кофейной гуще. Наша оценка — это сухая математика. Любой, даже самый сложный “Airbnb”, раскладывается на задачи.

Стоимость = Дизайн + Frontend + Backend + Интеграции + QA + DevOps + PM + Документация. Где каждый блок считается как объём × ставка роли (в часах).

Дальше одной строкой раскрываешь:

• Дизайн = (экраны + состояния) × ставка дизайнера.
• Frontend = (компоненты + логика связей + стейт-менеджмент) × ставка фронта.
• Backend = (сущности + связи + бизнес-операции) × ставка бэка.
• Интеграции = (кол-во интеграций + сценарии + нестабильность API) × ставка бэка.
• QA = (сценарии + платформы + регресс) × ставка QA.
• DevOps = (окружения + пайплайны + мониторинг + бэкапы) × ставка DevOps.
• PM = (синхронизации + коммуникации + управление изменениями) × ставка PM.
• Документация = (модули + глубина) × ставка.

Вот что нам нужно, чтобы калькулятор выдал чек:

1. Схема Базы Данных (Фундамент): Мы должны знать, что у нас десятки или сотни таблиц. И к этим таблицам нужно написать соответствующее количество CRUD-ов (Create, Read, Update, Delete) и настроить десятки связей.
2. Функции (Стены): Мы должны знать, что к этим таблицам привязано десятки или сотни логических операций (например, “расчет стоимости аренды с учетом погоды”).
3. Страницы и блоки (Отделка): Мы считаем каждый экран. Хедер, футер, карточка товара. Каждый блок тарифицируется: дизайн + верстка + интеграция.

Если у нас нет этих слагаемых, мы не сможем посчитать даже примерную смету.

Артефакты: Фабрика ясности

Чтобы получить эти слагаемые, мы прогоняем идею Макса через “Фабрику ясности” (Фазу 1 — Discovery & Design). На выходе мы получаем базовый пакет артефактов. Два главных — Figma и SoW, без которых разговор о деньгах — это разговор в режиме “давайте угадаем”.

1. Figma (Визуальная правда). Кликабельный прототип, где отрисованы все состояния, а их может быть на порядок больше, чем вам кажется. Не просто “красивая картинка”, а логика: что будет, если нажать сюда? А если ошибка? А если интернет отвалился?

2. Scope of Work (SoW) и стандарты качества. SoW — это границы объёма работ, deliverables и критерии приёмки, плюс стандарты качества:

• DoD (Definition of Done): Критерии готовности к приемке. Задача считается сделанной, когда она прошла тесты, код-ревью и залита на стейдж.

Диапазон: Пессимист vs Оптимист

Даже с идеальным промптом в IT остается фактор неопределенности. Поэтому профессиональная смета — это всегда диапазон.

• Оптимистичная оценка: Всё пошло идеально. Никаких багов, API банка не отвалилось, погода хорошая. (Спойлер: так не бывает почти никогда).
• Пессимистичная оценка (Safety Point — страховой потолок): Всё пошло не так. Всплыли все скрытые сложности, пришлось переписывать модуль.
• Это ваша страховка. Эта цифра работает как потолок: выше неё проект не поднимается при неизменном scope. Меняется объём — пересчитывается потолок.
• Реалистичная: То, куда мы планируем попасть.

Вывод:

• Принесли ТЗ на салфетке — получили “вилку страха”: от “сложно, но возможно” до “вообще нереально”. Диапазон без опоры на сценарии — это не оценка, это гадание на кофейной гуще с приговором.
• Принесли пакет артефактов (Figma + SoW + БД) — получили точный план, где каждый доллар обоснован математикой, а не фантазией менеджера.
• Вопрос к Максу (и к вам): на какой стороне этого уравнения вы хотите находиться — там, где цифры берутся с потолка, или там, где они выводятся из вашего продукта?

Экономика отношений: Фикс-прайс в кастоме создаёт ловушку

Макс смотрит на расчеты и задает вопрос, который кажется ему верхом рациональности:

— Окей, диапазон я понял. Но давайте мы просто зафиксируем эту цифру в договоре? Я плачу $50k, вы делаете “под ключ”. Риски — на вас.

Максу кажется, что он защитил свой бюджет. На самом деле, он только что предложил своему партнеру стать врагом.

Давайте честно: в модели Fixed Price у заказчика и разработчика диаметрально противоположные цели.

• Цель Макса: впихнуть в фиксированную сумму как можно больше фич.
• Цель Разработчика: сделать как можно меньше (и как можно дешевле), чтобы сохранить маржу и не уйти в минус.

Это не сотрудничество. Это перетягивание каната, где качество продукта — первая жертва.

Прямая речь CEO dZENcode:

— “В фикс-прайсе разработчик и клиент — враги. T&M — это когда мы в одной лодке и вместе гребём к результату, а не пытаемся выкинуть друг друга за борт.”

Парадокс “Эффективного менеджера”

Часто на этом этапе в игру вступает наемный директор или менеджер-оптимизатор. Его KPI — сэкономить бюджет здесь и сейчас. Он “прожимает” студию по цене, гордится собой и уходит.

Он не понимает одного: интерес оптимизатора заканчивается на этапе сдачи проекта. Интерес бизнеса — на этапе его жизни.

Если разработчик прогибается под фикс-прайс в условиях неопределенности, у него есть только два способа выжить:

1. Закладка рисков (x3): Вам назовут цену не $50k, а $150k. Вы заплатите за страх разработчика.
2. Экономия на невидимом: Разработчик подписывается на $50k, но начинает “резать косты”. Вместо Senior-архитектора код пишет Junior. Тесты вычеркиваются. Документация не пишется.

В итоге Макс получает продукт, который выглядит как конфетка, но технический долг в нём такой, что первое же обновление системы обрушит всё здание. Это зомби-продукт: он мертв, просто еще не знает об этом.

Альтернатива: Time & Material / Retainer (Подписка на успех)

Мы предлагаем другую модель. Вы платите не за обещание (которое может быть ложным), а за процесс и команду.

Это честная сделка:

• Мы строим вам “завод” по генерации денег.
• Мы зависим от вашего успеха.

Как говорит наш CEO:

— “Если то, что мы сделали, не заработает — вы сдохнете, и мы сдохнем, потому что потеряем партнера”.

Принцип “Платного свайпа”

Почему почасовая оплата (T&M) выгодна клиенту? Потому что она лечит от бесконечных переделок.

Представьте, что разработка — это Тиндер.

Если свайпы бесплатны, вы будете перебирать варианты бесконечно, не вникая в суть. “Давайте перекрасим кнопку”, “А давайте попробуем здесь анимацию”. Но если каждый свайп стоит хотя бы $1, вы трижды подумаете: “А нужно ли это моему бизнесу?”.

Оплата за итерации дисциплинирует. Она заставляет Макса (и нас) фокусироваться только на том, что реально приносит ценность.

Таблица: Где что работает?

Вывод: фикс-прайс — это попытка зафиксировать будущее, которого никто не знает. T&M — это инструмент управления будущим. Вы платите не за “кота в мешке”, а за команду, которая способна довести ваш продукт до релиза, даже если по дороге река превратится в море.

Практический Чек-лист: Тест на адекватность запроса

Прежде чем отправлять письмо с темой “Запрос коммерческого предложения” или вопросом “Сколько стоит?”, остановитесь на мгновение.

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

Отвечайте честно: “Да” или “Нет”.

1. Есть ли у вас “Визуальная правда” (Figma)? (Вы видели свой продукт глазами? Отрисованы ли все состояния экранов, включая ошибки и пустые поля? Или у вас только референсы “хочу как у Убера”?)
2. Есть ли у вас текстовая спецификация (Описание “каждого чиха”)? (Картинки недостаточно. Описана ли логика каждого клика текстом, известно ли количество связей и функций, структура БД? Денис, наш CEO, называет это “описать каждый вздох”. Без связки Figma + текстовая спецификация калькулятор не работает — мы просто не знаем, что считать.)
3. Приоритеты релизов (v0 / v1 / v2). (Понимаете ли вы, что именно считается “первым релизом”, а что уходит в “потом” без боли и самообмана?)
4. Реестр интеграций и данных. (Понятно ли, с чем интегрируемся (платежи, карты, 1С/CRM, партнёры), кто владелец API, есть ли песочницы, доступы, лимиты, и кто приносит ключи?)
5. Метрика успеха v1. (Что для вас “работает”: заявки, брони, конверсия, ретеншн, выручка? Как выглядит успех в цифрах — хотя бы на уровне ориентиров?)
6. Заложен ли бюджет на “Невидимый слой” (Management & Deploy)? (Понимаете ли вы, что код сам себя не напишет и на сервер не выложит? Управление процессом и деплой — это обязательные проценты к смете. Отказаться от них нельзя, иначе процесса просто не будет.)
7. Приняли ли вы решение по “Рисковым опциям” (QA & Docs)? (Готовы ли вы платить за тестирование и документацию?
8. Готовы ли вы к тому, что смета изменится после проектирования? (Понимаете ли вы, что первая цифра до этапа Discovery — это лишь гипотеза, а реальный бюджет рождается только после утверждения всех пунктов выше?)

Ваш вердикт:

• 0–3 “Да” — вы пришли за магией. Любая цифра будет “на глаз”, с коэффициентом неизвестности.
  Следующий шаг: Discovery & Design. Превратите идею в проект.
• 4–6 “Да” — вы уже в адекватной зоне, но есть “слепые пятна”, которые обычно и взрывают бюджет.
  Следующий шаг: короткий аудит материалов + быстрый Discovery, чтобы закрыть пробелы и дать диапазон.
• 7–8 “Да” — вы заказчик мечты. Можно считать смету, обсуждать контракт и план итераций.
  Следующий шаг: оценка с декомпозицией и коридором бюджета.

Заключение: Смена парадигмы

Вернемся к Максу в последний раз. Если бы он прочитал эту статью восемь месяцев назад, сцена в переговорной выглядела бы иначе.

Макс не спросил бы:

— “Сколько стоит?”.

Он бы сказал:

— “У меня есть бюджет, но я не хочу сжечь его на галлюцинации. Давайте начнем с проектирования. Я хочу увидеть чертеж завода, прежде чем мы начнем его строить.”

В этот момент Макс перестал быть покупателем “кота в мешке” и стал заказчиком Актива — системы, которой можно управлять. Да, он заплатит за этап Discovery. Но он не заплатит за переделку фундамента, когда дом уже построен до крыши.

Наш призыв прост:

Перестаньте искать того, кто назовет вам самую сладкую цену за 5 минут. Ищите того, кто вместо цифры даст вам список вопросов и артефактов для оценки.

Начните с Фазы 1 (Discovery & Design). Превратите вашу идею в пакет артефактов (Figma + текстовая спецификация + Схема БД). И тогда смета станет не предметом торга, а инструкцией по сборке вашего успеха.

Готовы сменить вопрос “Сколько?” на вопрос “Как?”. Приходите на проектирование.

Дзен-коан:

Учитель спросил ученика:

— “Сколько стоит построить мост через реку?”

Ученик ответил:

— “Тысячу золотых”.

Учитель спросил:

— “А если река завтра высохнет или превратится в море?”

Ученик замолчал. Учитель сказал:

— “Ты оценил камни, но забыл оценить гнев воды и капризы ветра. Пока не начертишь дно, не называй цену неба”.

P.S.: Какой пакет артефактов вы обычно приносите разработчикам на оценку? И совпадала ли хоть раз первая названная цена с финальной? Делитесь болью в комментариях.