---
title: "Кастомизация под заказчика: когда соглашаться и как считать"
url: "https://kzsaleshub.com/kastomizaciya-pod-zakazchika/"
type: "knowledge_article"
category: "Продукт"
language: "ru"
source: "KZSalesHub"
published: "2026-08-19"
last_updated: "2026-09-30"
---

# Кастомизация под заказчика: когда соглашаться и как считать

Кастомизация опасна не сама по себе, а тем, что её стоимость платится не в момент продажи, а через два года — при каждом обновлении, каждой миграции и каждом уходе разработчика, который её писал. Решение принимается по трём осям: обобщается ли требование, кто платит за поддержку и где физически живёт код. Если требование не обобщается, поддержку никто не оплачивает, а код лежит в основной ветке — соглашаться нельзя ни за какие деньги.

## Три вида доработки, которые путают между собой

| Вид | Где живёт | Кто платит за поддержку | Когда уместно |
| --- | --- | --- | --- |
| Настройка | В продукте, через интерфейс или конфиг | Никто, это штатная функция | Всегда — к этому и надо стремиться |
| Расширение | Отдельный модуль или интеграция на публичных точках подключения | Заказчик или партнёр, разово и за обновления | Требование специфичное, но продукт его допускает |
| Форк | Изменённая копия основного кода | Вы, вечно, и дороже, чем думаете | Практически никогда |

Большинство споров возникает потому, что продажа обещает «настройку», разработка слышит «расширение», а в итоге получается форк.

## Порядок принятия решения

1. **Перевести требование в задачу.** Заказчик просит поле в карточке — выясните, что он с этим полем собирается делать. В половине случаев задача решается уже имеющимися средствами, просто про них не рассказали на демонстрации.
2. **Проверить обобщаемость.** Спросите себя: продадим ли мы это следующим трём клиентам как преимущество? Если да — это продукт, и платить за него разработкой нормально.
3. **Посчитать стоимость владения, а не разработки.** К оценке разработки прибавьте сопровождение при каждом релизе на горизонте трёх лет. Обычно это удваивает цифру.
4. **Выбрать место в архитектуре.** Публичная точка подключения — расширение, приемлемо. Правка ядра — форк, отказ.
5. **Оформить деньгами.** Разовая оплата не покрывает сопровождение. Либо доработка входит в продукт и оплачивается подпиской всех, либо у неё есть отдельная строка обслуживания.
6. **Записать решение.** Кто попросил, что решили, почему, кто платит. Через год этот список — самый ценный документ при планировании версии.

Практическое правило для узкого рынка: доля выручки от одного заказчика выше тридцати процентов означает, что вы уже не продуктовая компания, а подрядчик этого заказчика. Это не приговор, но модель другая — и цены, и договор, и планирование строятся иначе.

## Как отказывать, не теряя сделку

Отказ проходит легче, когда вместо «мы этого не делаем» звучит альтернатива и срок. Три формулировки, которые работают:

- **Обходной путь сейчас, продукт потом.** «Сегодня это решается вот так — не идеально, но работает. В плане на следующий квартал стоит нормальная поддержка, покажем в бета-версии.»
- **Отдельный проект с ценой.** «Мы это сделаем, но это работа, а не настройка. Оценка — столько-то, сопровождение — столько-то в год. Решайте, стоит ли.»
- **Честная граница.** «Мы этого делать не будем, потому что это ломает продукт для остальных. Если это критично — вам нужен другой класс решения, и мы скажем какой.»

Третья формулировка теряет часть сделок и сохраняет продукт. На дистанции она выгоднее.

## Что смотреть в договоре

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

- **Кому принадлежит результат.** Если права на доработку уходят заказчику, вы не сможете продать её следующему. Формулировка «исключительные права заказчику» на модуль продукта — типичная и дорогая ошибка.
- **Обязательство по срокам.** Дата в договоре превращает продуктовую задачу в неустойку.
- **Условия обновления.** Кто и за чей счёт переносит доработку на новую версию — это надо назвать до подписания, а не через полтора года.

**Как понять, что доработка обобщается?**

Попробуйте описать её в одном предложении так, чтобы в нём не было названия компании-заказчика и её внутренних терминов. Если не получается — не обобщается.

**Можно ли брать доработки как способ выжить на старте?**

Можно и часто нужно, но осознанно и с планом выхода: какая доля выручки от проектов допустима и к какому сроку она снижается. Без этого проектная выручка съедает продуктовую команду.

**Кто должен говорить заказчику «нет»?**

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

**Что делать с уже накопленными форками?**

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

## Связанное

- [Управление жизненным циклом продукта](https://kzsaleshub.com/framework/plm/)
- [Ценообразование и упаковка](https://kzsaleshub.com/framework/pricing-packaging/)
- [Модель Кано](https://kzsaleshub.com/framework/kano-model/)
- [Роль: руководитель внедрения](https://kzsaleshub.com/roles/delivery-manager/)
- [Роль: пресейл](https://kzsaleshub.com/roles/presale/)

Три вопроса до согласия: обобщается ли требование, кто платит за сопровождение, где живёт код. Настройка — да, расширение — за деньги и с условиями, форк — нет.

---
Источник: https://kzsaleshub.com/kastomizaciya-pod-zakazchika/