Бизнес · 7 мин чтения

Разная оценка стоимости разработки: почему цены в сметах не совпадают

Прислал клиент ТЗ трём разработчикам - получил три сметы: 30 000 ₽, 80 000 ₽ и 200 000 ₽. Задача одна, набор функций одинаковый, а цифры отличаются в разы. Я сталкиваюсь с этим с обеих сторон: когда сам оцениваю проект и когда клиент показывает смету конкурента и спрашивает, почему у меня дороже или дешевле. Разная оценка стоимости разработки - не признак того, что кто-то жулик, а следствие того, что каждый разработчик считает разные вещи под одним и тем же названием задачи.

Из чего складывается цена, которую не видно в тексте ТЗ

Клиент читает ТЗ и видит список функций: форма на сайте, интеграция с СДЭК, приём оплаты. Разработчик читает то же ТЗ и видит десятки решений, которые в тексте не прописаны: как обрабатывать ошибку API, что показывать пользователю при таймауте, куда логировать сбои, кто будет отвечать за интеграцию через полгода, когда СДЭК поменяет формат ответа.

На практике интеграция WooCommerce с эквайрингом T‑Bank у меня занимала от трёх дней до двух недель - в зависимости от того, нужен ли только приём платежа или ещё возвраты, сверка чеков по 54-ФЗ и обработка вебхуков о статусе оплаты. Клиент видит одну строчку «подключить оплату», а по факту это три разных объёма работы с тремя разными ценами.

То же самое с ботами на aiogram: «сделайте бота для записи на услугу» может означать простую анкету с кнопками, а может - бота с базой клиентов, напоминаниями через планировщик, интеграцией с CRM и админкой для менеджера. Формулировка одна, трудозатраты разные на порядок.

Почему один и тот же скрипт для Tilda стоит 3000 ₽ у одного и 40000 ₽ у другого

Кастомный скрипт для Tilda - хороший пример, где разброс цен выглядит пугающе, но объясняется просто. Простая доработка вроде маски телефона в поле формы или скрытия блока по условию у меня стоит от 3 000 ₽ - это час-два работы с готовым паттерном. Комплексная интеграция с CRM, эквайрингом и расчётом доставки через СДЭК - от 40 000 ₽, потому что там нужно синхронизировать статусы заказа между тремя системами, обрабатывать конфликты данных и тестировать сценарии, когда одна из систем недоступна.

Заказчик часто не различает эти два случая, пока не получит смету. Разработчик, который берёт 3 000 ₽ за задачу, на самом деле имел в виду точечную правку, а клиент подразумевал полноценную интеграцию. Отсюда и конфликт ожиданий уже после старта работ. Если задача укладывается в готовый паттерн - доработку СДЭК, синхронизацию с amoCRM, форму с валидацией - иногда дешевле взять уже отлаженный код из библиотеки готовых скриптов, чем оплачивать разработку с нуля.

Что обычно входит в простую доработку, а что - в комплексную интеграцию

Простая доработка (от 3 000 ₽) Комплексная интеграция (от 40 000 ₽)
Валидация одного поля формы Синхронизация заказов с CRM в реальном времени
Показ/скрытие блока по условию Расчёт доставки через API СДЭК с обработкой ошибок
Кастомный скролл или анимация Приём и сверка платежей через эквайринг
Правка стилей под бренд Логирование сбоев и уведомления менеджеру

Бесплатный материал

🎁 Полезный скрипт в подарок

Подпишитесь на Telegram - пришлю готовый скрипт по этой теме.

Без спама. Отписка в 1 клик.

Опыт, стек и глубина тестирования - три причины разного счёта

Разработчик с двумя годами практики и разработчик с восемью лет считают задачу по-разному не потому, что один жаднее. Опытный закладывает время на кейсы, которые новичок пока не видел: что произойдёт, если пользователь дважды нажмёт «оплатить», что делать при обрыве соединения с СДЭК посреди запроса, как вести себя боту, если Telegram API вернёт 429 при рассылке.

Выбор стека тоже двигает цену в обе стороны. Автоматизацию, которую можно собрать в n8n за пару дней от 25 000 ₽, кто-то будет писать кастомным кодом на Python неделю - и цена вырастет, хотя результат для пользователя внешне одинаковый. Обратная ситуация: парсинг сайта с нестандартной защитой от ботов на голых запросах requests не соберёшь, там нужна ротация IP, рандомизация отпечатка браузера и соблюдение rate-limit, чтобы не получить бан - такой парсинг у меня стоит от 20 000 ₽, а на бирже фриланса можно встретить и 5 000 ₽ за то же название задачи, где на деле сдадут скрипт, падающий после первого дня работы.

Глубина тестирования - ещё один незаметный множитель. Разработчик, который прогоняет 10 сценариев перед сдачей, тратит на это отдельный день. Тот, кто сдаёт после первого успешного запуска на своих данных, экономит клиенту деньги здесь и сейчас, но перекладывает риск багов на боевую эксплуатацию.

Как оценивают риск и допы, которые не попали в ТЗ

Любая смета - это не только время на написание кода, но и буфер на то, что задача изменится по ходу работы. Клиент присылает ТЗ на бота для записи, а через неделю просит добавить оплату онлайн и напоминания за день до визита. У кого-то в цене изначально заложен запас на такие уточнения, у кого-то - нет, и тогда каждое расширение оформляется отдельным счётом.

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

Отдельно стоит разделять цену разработки и цену сопровождения после запуска. Техподдержка у меня оформляется отдельно, от 15 000 ₽ в месяц, и не входит в стоимость самого проекта - это тоже частая причина, почему одна смета выглядит дороже другой: в неё уже включён первый месяц сопровождения, а в другой - нет.

Как сравнивать сметы, если цифры разные

Сравнивать нужно не итоговую сумму, а состав работ за ней. Я советую клиентам задавать разработчикам одни и те же вопросы и смотреть на разницу в ответах, а не в цифрах:

  • Что входит в тестирование - один сценарий или набор пограничных случаев
  • Кто чинит баги, найденные в первую неделю после сдачи, и на каких условиях
  • Заложена ли в цену обработка ошибок сторонних API (СДЭК, эквайринг, Telegram)
  • На каком стеке будет сделана автоматизация - n8n, кастомный Python-скрипт или связка из готовых сервисов
  • Сколько итераций правок по дизайну или логике включено до сдачи

Если смета выглядит подозрительно дешёвой, почти всегда это значит, что из неё вычеркнули тестирование, обработку ошибок или пограничные случаи. На рынке фриланса цена на интеграцию с СДЭК может стартовать от 10 000 ₽ и доходить до 150 000 ₽ у студий - и это не значит, что дешёвый исполнитель хуже кодит, просто он посчитал только happy path, без обработки сбоев и без сверки статусов заказа.

Разобраться перед стартом

Консультация

от 3 000 ₽

Подробнее →

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

Почему дешёвая смета не всегда невыгодна?

Если задача простая и без сторонних интеграций - например, точечная правка скрипта на Tilda - дешёвая смета вполне может закрывать весь объём работы честно. Проблема начинается там, где задача выглядит простой в тексте ТЗ, но требует обработки ошибок, сверки данных между системами или тестирования на реальных сценариях, а в смете это не учтено.

Можно ли просить разработчика обосновать цену?

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

Из чего складывается цена Telegram-бота?

Базовый функционал - меню, форма записи, простая рассылка - укладывается в нижнюю границу цены, у меня это от 30 000 ₽. Стоимость растёт с добавлением интеграции с CRM, оплаты внутри бота, базы знаний с ответами через RAG или админ-панели для менеджера - каждый такой блок считается отдельно, потому что требует своего тестирования и обработки ошибок.

Как понять, что смета занижена и проект «утонет» в допах?

Настораживает, если разработчик не задаёт уточняющих вопросов по ТЗ и называет цену сразу, без обсуждения интеграций и пограничных случаев. Я обычно перед оценкой уточняю у клиента, что должно происходить при сбое стороннего сервиса и нужна ли поддержка после запуска - если это не обсуждается на старте, велика вероятность, что цена вырастет уже в процессе работы через дополнительные счета.

Сравнение смет по составу работ, а не по итоговой цифре, экономит нервы обеим сторонам - и разработчику не приходится оправдываться за доплаты, и клиент понимает, за что платит с самого начала.

Есть задача?

Обсудим в мессенджере

Расскажите, что нужно сделать — отвечу в течение 4 часов в рабочее время. Первая консультация бесплатно.

Самозанятый Калинкин Н. А. · работаю с физлицами и юрлицами

Продолжая пользование настоящим сайтом Вы выражаете своё согласие на обработку Ваших персональных данных (файлов куки) с использованием Yandex.Metrika.
Понятно