~/oybek.dev
статьи
Process6 мая 2026 г.· 8 мин чтения

Оценка за 48 часов: как назвать цену веб-проекта без накруток

Фикс-прайс на веб-проект за 48 часов звучит как повод раздуть смету. Это не так — если сначала убрать неопределённость через discovery. Делюсь процессом, вопросами, которые снимают риски, и случаями, когда я не даю фикс-прайс.

Фиксированная цена на веб-проект за 48 часов звучит как повод заложить запас: назвать цену повыше, спрятать буфер и надеяться, что угадал. Именно так работает большинство агентств — и именно поэтому клиенты разучились доверять фиксированным ценам. За примерно 19 лет я оценил и зафиксировал стоимость десятков проектов, и весь фокус прямо противоположен буферу: провести на старте столько discovery, чтобы угадывать почти ничего не осталось. Оценка перестаёт быть пари, обёрнутым в маржу, и становится арифметикой по объёму работ, который обе стороны действительно понимают. Когда уложиться в 48 часов не получается, я не закладываю запас — я говорю вам, что сначала проекту нужен платный discovery, и подробно объясняю почему.

Вот процесс, по которому я быстро оцениваю объём веб-проекта и честно определяю цену — будь то маркетинговый сайт, headless-коммерция или внутренний инструмент.

Почему фиксированная цена безопаснее для обеих сторон

Стандартный совет звучит так: «всегда работай по схеме time-and-materials, фиксированная цена — это ловушка». Это правда, когда оценка делается небрежно. И это ровно наоборот, когда оценка сделана как надо.

При time-and-materials весь риск несёт клиент. Каждая моя промашка в оценке, каждая кроличья нора, каждое «раз уж мы тут» — за всё платит он. У него нет потолка и нет способа планировать денежный поток. А у меня появляется тихий стимул работать медленнее.

При настоящей фиксированной цене риск несу я — риск собственной эффективности, а клиент получает число, которое можно вынести на совет директоров, показать сооснователю или взять в банк. Мой стимул переворачивается: закончить чисто, закончить раньше. Подвох — в словах «как надо». Фиксированная цена на размытый объём — это просто перенос моей неопределённости на ваш счёт в виде жирного буфера. Фиксированная цена на чёткий объём — честная сделка: я беру на себя разброс в обмен на право назвать уверенное число без запаса.

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

Сравнение в две колонки: кто несёт риск при time-and-materials и при фиксированной цене
Кто несёт риск, зависит от того, как устроено ценообразование работы

Вопросы для discovery, которые убирают угадывание

Буфер рождается из неизвестного. Убейте неизвестное — и буферу негде прятаться. Я провожу звонок на 45–60 минут, а затем — короткий письменный follow-up. Вот вопросы, которые делают основную работу.

Что именно мы заменяем или с чем конкурируем?

«Сделайте нам сайт как X» говорит мне больше, чем три абзаца требований. Если вы указываете на референс, я могу оценить реальный объём за минуты — типы страниц, паттерны взаимодействия, объём контента. Когда Trivandi пришли ко мне, референс плюс их контент-модель сделали сборку на Next.js + Sanity элементарно оцениваемой. Отсутствие референса означает, что мы проектируем вслепую, — а это уже другой, более долгий разговор.

Кому принадлежит контент и в каком он состоянии?

Это тот вопрос, который незаметно удваивает сроки. Контентный сайт живёт или умирает в зависимости от модели CMS и того, кто её наполняет. Мне нужно знать, сколько шаблонов страниц, сколько языков, кто пишет тексты и существует ли контент вообще. Один только двуязычный контент — тот, что я моделирую через локализацию на уровне полей в Sanity, — переформатирует схему, матрицу QA и дату запуска. Если ответ звучит как «мы напишем его уже в ходе разработки» — это тревожный сигнал, а не деталь.

Что должно интегрироваться и работают ли эти системы уже сейчас?

Платежи, авторизация, PIM, ERP, CRM, фид остатков. Интеграции — это место, где умирают фиксированные цены, потому что неизвестное здесь — не мой код, а качество системы на той стороне. Для коммерческих проектов я спрашиваю, вы на Shopify Hydrogen или хотите собственную инфраструктуру на Medusa, — потому что один этот ответ переформатирует оценку. На региональной EV-платформе NIO поток от конфигуратора до оформления заказа затрагивал несколько систем, и я заложил риск интеграции явно, а не закопал его.

Что на самом деле означает «готово»?

«Готово» — это запуск? Запуск плюс месяц правок после релиза? Готово вместе с SEO, аналитикой и передачей CMS, чтобы ваша команда стала самостоятельной? Каждая трактовка — это другое число. Я заставляю клиента произнести это вслух, а затем записываю, потому что «готово» — самое дорогое слово в любом коммерческом предложении.

Кто принимает решения и как быстро?

Проект с одним лицом, принимающим решения и отвечающим за день, выпускается по другой цене, чем проект с комитетом, который собирается раз в две недели. Задержка решений — это реальная стоимость. Я не закладываю под неё буфер втихую — я называю её прямо и прописываю в предложении SLA на согласования.

Рабочий лист звонка-discovery с пятью ключевыми вопросами по оценке и короткими полями для ответов
Вопросы важнее ответов — они вскрывают то, о чём никто не подумал упомянуть

Тревожные сигналы: проекту нужен discovery, а не оценка

Иногда 48 часов недостаточно, и честный шаг — сказать об этом. Вот сигналы, по которым я предлагаю платный спринт discovery вместо фиксированной цены:

  • Объём описан в терминах результатов, а не функций. «Мы хотим доминировать на рынке» — это цель, а не спецификация. Я могу зафиксировать цену на функции; я не могу зафиксировать цену на амбицию.
  • Никто не может назвать интеграции. Если «это должно общаться с нашими системами» нельзя превратить в список конкретных систем с документацией, неизвестное слишком велико, чтобы его оценить.
  • Требования приходят 40-страничным PDF, который никто не готов отстаивать. Длинные документы создают ощущение безопасности и обычно прячут противоречия. Я предпочту бриф на одну страницу и острый 60-минутный звонок.
  • Модель данных по-настоящему нетривиальна. Большинство сайтов — вариации паттернов, которые я уже выпускал. Когда базовая предметная область действительно новая — движок ценообразования, алгоритм мэтчинга, мобильное приложение с офлайн-синхронизацией вроде PropertyCheck, — я сначала делаю spike, и только потом оцениваю.
  • В брифе есть AI, но нет сценария использования. «Добавьте AI» — это не объём. Я выпускал AI-функции, которыми клиенты реально пользуются на Vercel AI SDK, и те, что сработали, начинались с конкретной задачи, а не с технологии.

Предложить здесь discovery — не значит проиграть сделку. Это самая дешёвая страховка, которую мы оба когда-либо купим. Несколько оплаченных дней регулярно превращают проект, который я заложил бы с запасом в 40%, в тот, что я могу оценить впритык.

Как я выстраиваю коммерческое предложение

Когда discovery завершён, предложение пишется почти само. Я держу его в пределах нескольких страниц и фиксированной структуры.

  1. Объём как список того, что включено, — и параллельный список того, что нет. Исключения — самая ценная часть. Именно здесь scope creep останавливают до того, как он начнётся. «Ввод контента на трёх языках» стоит рядом с «текст перевода предоставляет клиент».
  2. Фиксированная цена, по фазам. Я разбиваю работу на этапы с собственными результатами и оплатами. Фазы позволяют клиенту стартовать, не обязуясь сразу выложить весь бюджет, и дают нам обоим чистую точку контроля. Для сборки headless-коммерции это может быть фундамент и CMS, затем каталог и страницы товаров, затем оформление заказа и интеграции, затем запуск.
  3. Стек, названный и обоснованный. Я говорю вам, на чём строю и почему — React и Next.js для приложения, Laravel для контентного бэкенда, Umbraco там, где команда клиента уже в нём живёт, как в случае Emarat. Никакой загадочности, никакого vendor lock-in через неясность.
  4. Что меняет цену. Короткое и явное условие о запросах на изменения. Новый объём — это нормально, это просто новая строка в смете, оценённая тем же честным способом. Именно это позволяет фиксированной цене пережить столкновение с реальностью.
  5. График с домашним заданием для клиента. Даты зависят от того, придут ли вовремя контент и согласования, поэтому эти зависимости живут в графике, а не в мелком шрифте.

Вот и всё. Закладывать запас не во что — неизвестное разрешилось в discovery, исключения ограничивают объём, а условие об изменениях покрывает то, что я действительно не мог предвидеть.

Макет одностраничного предложения: объём, исключения, поэтапное ценообразование и условие об изменениях
Список исключений и условие об изменениях — вот что делает фиксированную цену безопасной

Что на самом деле обещает фиксированная цена

Фиксированная цена — не фокус и не приём продаж. Это обещание, которое я могу дать только после того, как убрал достаточно неопределённости, чтобы его сдержать. 48 часов покупают уверенное число; discovery за ним — вот что делает это число честным. Если проект слишком размыт, чтобы честно оценить его за два дня, я скажу вам и это — и мы потратим несколько оплаченных дней, чтобы сделать его оцениваемым, что дешевле буфера, который вы иначе оплатили бы, сами того не зная.

Если вы выбираете между фракционным CTO и агентством, и кто-то называет крупное круглое число через час после звонка, спросите, какие неизвестные он разрешил, чтобы к нему прийти. Ответ скажет вам всё.

Частые вопросы

Как вы даёте фиксированную цену на веб-проект за 48 часов?

Эти 48 часов — в основном discovery, а не оценка. Сфокусированный 60-минутный звонок плюс короткий письменный follow-up разрешают пять вещей, которые на самом деле определяют стоимость: референс и объём, владение контентом, интеграции, определение «готово» и скорость принятия решений. Когда этих неизвестных не остаётся, ценообразование становится арифметикой, а не догадкой, — и закладывать буфер не во что.

Что лучше для веб-проекта — фиксированная цена или time-and-materials?

Это целиком зависит от качества оценки. Time-and-materials перекладывает весь риск на клиента и лишает разработчика стимула двигаться быстро. Фиксированная цена на хорошо оценённом проекте переворачивает и то и другое: разработчик несёт риск эффективности, а клиент получает число, под которое можно планировать. Фиксированная цена — ловушка только тогда, когда объём размыт, потому что в этом случае буфер прячется внутри цены.

Каких вопросов мне ждать в ходе discovery по веб-проекту?

Ждите вопросов о том, что вы заменяете или с чем конкурируете, кому принадлежит контент и существует ли он уже, с какими системами должна интегрироваться сборка, что на самом деле означает «готово» (запуск, поддержка, передача) и кто принимает решения и как быстро. Если разработчик пропускает эти вопросы и всё равно называет цену — число заложено с запасом, чтобы покрыть то, о чём он не спросил.

Когда веб-проекту нужен платный discovery вместо оценки?

Когда объём описан как результаты, а не функции; когда никто не может назвать интеграции; когда базовая модель данных по-настоящему нетривиальна; или когда «AI» появляется в брифе без конкретного сценария использования. В этих случаях несколько оплаченных дней discovery обходятся куда дешевле буфера — или перерасхода, — который вызвала бы преждевременная фиксированная цена.

Как вы останавливаете scope creep на проекте с фиксированной ценой?

С помощью явного списка исключений и условия о запросах на изменения в предложении. Исключения ограничивают объём, называя то, что не входит, а условие об изменениях превращает новую работу в прозрачную строку сметы, оценённую тем же честным способом. Новый объём — не повод для спора, это новое число, согласованное до начала любых работ.

Какой стек вы используете для веб-проектов с фиксированной ценой?

Это зависит от задачи, и я называю его в предложении: Next.js и React для приложений, Sanity для контентных сайтов, Shopify Hydrogen или Medusa для коммерции — в зависимости от того, какой объём инфраструктуры вы хотите контролировать, Laravel или Umbraco для контентных бэкендов и React Native для мобильных приложений. По состоянию на середину 2026 года это значит Next.js 16 и React 19, а не предыдущие мажорные версии. Выбор обосновывается письменно, а не подразумевается по умолчанию.

Есть похожая задача?

Начать проект