Вопрос фикс или почасовая оплата разработки возникает на первой же встрече с заказчиком, обычно сразу после того как я называю сроки и прошу описать задачу подробнее. У каждой модели своя логика распределения риска между исполнителем и клиентом, и ошибка в выборе схемы оплаты обходится дороже, чем кажется на старте проекта. Разбираю, как считается цена в обоих случаях, где какая модель работает лучше и как я оцениваю проект на практике, когда заказчик сам не может определиться.
Как работает фиксированная цена на разработку
Фиксированная цена значит, что я оцениваю весь объем работ до старта и называю одну сумму за результат. Для этого нужно техническое задание или хотя бы подробное описание функционала: сколько страниц на сайте, какие интеграции, какой дизайн уже готов. Например, сайт на Tilda у меня стоит от 30 000 ₽, интернет-магазин под ключ от 80 000 ₽, кастомная CRM-панель на React от 100 000 ₽.
Чтобы зафиксировать цену, я закладываю в оценку буфер на непредвиденные сложности, обычно 15-25% сверх честной оценки часов. Если бы я считал в ноль, любая неожиданность вроде кривого API у стороннего сервиса или отсутствия доступов к хостингу съедала бы мою маржу. Заказчик буфер не видит и не платит его отдельно, но он зашит в итоговую сумму.
Обратная сторона: любое изменение сверх согласованного ТЗ оформляется отдельно, через доплату или новый этап. Если на середине проекта заказчик решает добавить фильтр по цене в каталог, которого не было в исходном ТЗ, это новая задача с новой оценкой, а не бесплатная правка.
Как устроена почасовая оплата программиста
При почасовой оплате я фиксирую ставку в час и веду учет времени по задачам, обычно с недельным отчетом, где расписано, сколько часов ушло на что. Схема логична, когда объем работ заранее не ясен: техподдержка у меня стоит от 15 000 ₽ в месяц, и по сути это пакет часов на исправления, мелкие доработки и консультации.
Здесь заказчик платит за фактически потраченное время, а не за усредненный прогноз. Если задача оказалась проще, чем думали, счет меньше. Если сложнее, например при интеграции эквайринга Т‑Банка в WooCommerce вылезла нестандартная конфигурация магазина, счет вырастет, и это открыто видно в отчете, а не спрятано в общей сумме.
Риск здесь смещается на заказчика: бюджет проекта заранее не известен точно, есть только оценка в часах с погрешностью. Поэтому я обычно называю вилку часов по задаче и предупреждаю, если фактика начинает выходить за верхнюю границу, вместо того чтобы молча накручивать счет.
Бесплатный материал
🎁 Полезный скрипт в подарок
Подпишитесь на Telegram - пришлю готовый скрипт по этой теме.
Без спама. Отписка в 1 клик.
Фикс и почасовая оплата разработки в сравнении
| Критерий | Фиксированная цена | Почасовая оплата |
|---|---|---|
| Бюджет проекта | Известен заранее | Оценивается вилкой, уточняется по факту |
| Гибкость изменений | Низкая, доп. работы оформляются отдельно | Высокая, задачи меняются по ходу |
| Кто несет риск недооценки | Исполнитель | Заказчик |
| Нужен подробный ТЗ на старте | Да, обязательно | Не обязательно |
| Подходит для | Лендинги, типовые интеграции, доработки Tilda | AI-интеграции, n8n-автоматизация, растущие боты, техподдержка |
Когда фиксированная цена выгоднее заказчику
Фикс хорошо работает, когда задача описывается конечным списком: сделать лендинг по готовому дизайну, настроить расчет зон доставки СДЭК на Tilda, ограничить количество активаций промокода. Под последнюю задачу у меня уже есть готовое решение, и клиенты часто берут его вместо разработки с нуля именно потому что цена и результат известны заранее, можно посмотреть готовые скрипты для Tilda и прикинуть, закрывает ли типовое решение задачу.
Фикс также логичен для небольших бюджетов и разовых проектов, где заказчику важнее не выйти за рамки сметы, чем сохранить гибкость в процессе. Лендинг под рекламную кампанию, доработка Tilda-скрипта от 3 000 ₽, разовая интеграция вроде подключения зон доставки, все это задачи с понятным объемом, где фиксированная цена снимает тревогу за бюджет.
Когда почасовая оплата разработки оправдана
Почасовая модель выигрывает там, где объем работ формируется по ходу проекта. Классический пример, Telegram-бот на aiogram, который на старте задумывался простым каталогом товаров, а через месяц обрастает оплатой, персональными рассылками и админкой для менеджера. Фиксировать цену на такой проект в начале означает либо занижать оценку и терять на допах, либо закладывать огромный буфер на риски, которых может и не случиться.
То же с AI-интеграциями: чат-бот с базой знаний на Claude API часто начинается с исследования, какие данные вообще есть у заказчика и как их превратить в векторную базу для RAG. Пока не понятен объем документов и структура данных, честная фиксированная оценка невозможна, поэтому такие задачи я беру от 50 000 ₽ с почасовым уточнением на этапе исследования.
Автоматизация в n8n тоже часто начинается с разведки: какие сервисы использует заказчик, где у них есть API, а где придется городить обходной путь через вебхуки. Пока схема процессов не нарисована, оценивать фиксом рискованно для меня и невыгодно для заказчика, который в итоге переплачивает за чужой риск.
Риски, которые обычно не проговаривают заранее
У фикса главный риск для заказчика в том, что исполнитель закладывает избыточный буфер или урезает качество, если недооценил сложность. Встречались проекты, где разработчик после подписания фикса начинал экономить на тестировании просто чтобы уложиться в смету, и заказчик получал рабочий, но хрупкий продукт.
У почасовой оплаты риск обратный: бюджет не ограничен сверху, если заранее не договориться о потолке часов. Добросовестный исполнитель сам предупредит, когда оценка начинает расползаться, но проверить это со стороны заказчика сложно без отчетности. Поэтому я всегда фиксирую верхнюю границу по часам в переписке до начала работы и останавливаюсь для согласования, если вижу, что выхожу за нее.
Гибридный подход, который я использую на практике
На практике чистый фикс или чистая почасовая оплата разработки редко подходят целиком под весь проект. Обычно я разбиваю работу на этапы: MVP или основной функционал оцениваю фиксированной ценой по четкому ТЗ, а последующие доработки и техподдержку веду почасово или по абонементу от 15 000 ₽ в месяц.
Для веб-сервисов и SaaS с бюджетом от 300 000 ₽ и сроком от 8 недель фикс на весь проект вообще не имеет смысла, там слишком много неопределенности на старте. Вместо этого фиксирую цену на первый спринт с понятным набором экранов, а дальше пересчитываю по факту вместе с заказчиком после каждого этапа.
Перед оценкой любого проекта я обычно провожу короткий созвон, чтобы понять реальный объем задачи и предложить модель оплаты, которая не создаст проблем ни мне, ни заказчику.
Разобраться перед стартом
Консультация
от 3 000 ₽
Подробнее →Частые вопросы
Как понять, что мне подойдет: фикс или почасовая оплата разработки?
Если задачу можно описать конечным списком экранов и функций и у вас есть референсы или готовый дизайн, берите фикс, вы будете точно знать бюджет. Если продукт развивается по ходу работы, как стартап на этапе поиска модели, или задача исследовательская, вроде AI-интеграции с неизвестным объемом данных, почасовая оплата честнее для обеих сторон.
Можно ли перейти с почасовой оплаты на фиксированную цену в процессе проекта?
Да, и я так делаю регулярно. Обычно первые недели работы по новому направлению веду почасово, пока не проясняется реальный объем, а как только границы задачи становятся понятны, перевожу оставшуюся часть на фикс по согласованному списку функций.
Как проверить, что разработчик на почасовой оплате не завышает часы?
Просите еженедельный отчет с разбивкой по задачам, а не общую цифру часов в конце месяца. Договоритесь заранее о верхней границе по каждой крупной задаче и просите предупреждать, если оценка начинает расти. Резкий рост часов без объяснений в переписке или коммитах, повод спросить прямо, что пошло не так.
Что дешевле в итоге - фикс или почасовая оплата?
Зависит от того, насколько точно описана задача на старте. Для понятных проектов фикс обычно дешевле, потому что заказчик не платит за буфер исполнителя дважды: один раз в почасовой ставке, второй раз в собственном времени на контроль процесса. Для проектов с неопределенным объемом почасовая оплата часто выходит дешевле фикса, потому что исполнитель не закладывает страховку на риски, которые могут не реализоваться.