Перейти к контенту
B2B-платформы

Своя платформа или готовое решение: когда заказная разработка B2B окупается, а когда нет

Честный разбор, когда для B2B выгоднее коробка (Битрикс24, amoCRM, SaaS), а когда — заказная платформа. Критерий 30% доработок, стоимость владения, сроки и три вопроса, которые решают выбор.

Автор: Николай Мазур · · 7 мин чтения · Read in English

Короткий ответ: заказную B2B-платформу стоит строить, когда готовые коробки требуют больше 30% доработок или не держат критичную для вас бизнес-логику — сложные роли, документооборот, отраслевые требования. Во всех остальных случаях дешевле и быстрее взять Битрикс24, amoCRM или профильный SaaS. Хорошая студия отговорит вас от собственной разработки чаще, чем предложит её — потому что кастомная платформа выигрывает не ценником внедрения, а стоимостью владения на горизонте 2–3 лет.

Разберём, как принять это решение без ошибки на миллионы.

Здесь речь о выборе между коробкой и своей системой. Если вы искали другое различие, между проектным и продуктовым способом вести саму работу, оно разобрано отдельно: заказная продуктовая разработка. Там про то, кто отвечает за систему после запуска; вопрос «покупать или строить» решается до этого.

Почему «сделаем своё» — самая дорогая гипотеза

Соблазн понятен: готовая CRM «почти подходит», но не хватает пары полей, одного статуса и интеграции со складом. Кажется, что своя система решит всё и навсегда. На практике заказная разработка B2B-платформы — это от 3 млн ₽ и 4–6 месяцев до production, плюс поддержка и развитие после запуска.

Поэтому первый вопрос не «что мы хотим», а «что сломается, если мы возьмём коробку и потерпим её ограничения?». Если ответ — «ничего критичного», разработка не нужна. Своё имеет смысл ровно тогда, когда ограничения коробки стоят вам денег каждый месяц.

Правило 30% доработок

Рабочий критерий, которым мы пользуемся на пресейле:

  • Коробка закрывает процесс на 70%+ из коробки или мелкими настройками — берите коробку (Битрикс24, amoCRM, отраслевой SaaS). Дорабатывать custom тут — выбрасывать деньги.
  • Коробка требует больше 30% доработок (кастомные модули, переписанная логика, тяжёлые интеграции) — считайте заказную разработку. На этом пороге стоимость «допиливания» чужого продукта догоняет и перегоняет стоимость своего, а вы всё равно остаётесь заложником чужих обновлений.

30% — это не про число полей, а про бизнес-логику. Добавить поле и отчёт коробка переживёт. А вот когда у вас четыре роли (клиент, партнёр, менеджер, администратор), процесс завязан на документах, статусах, оплатах и согласованиях, и всё это не ложится в модель готовой CRM — вы уже за порогом.

Дерево решения между коробкой и заказной B2B-платформой: если доработок до 30 процентов — берётся готовое решение, если больше и бизнес-логика не ложится в модель продукта — считается заказная разработка со сравнением стоимости владения за 2–3 года; перед любым вариантом стоит попробовать самое дешёвое решение, закрывающее проблему

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

Пять признаков, что вы переросли коробку

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

  • Несколько ролей с разными правами и интерфейсами — не «менеджер и админ», а клиент + партнёр + несколько внутренних ролей со своими рабочими местами.
  • Процесс живёт в документах и статусах — согласования, генерация договоров и актов, многошаговые workflow, которые в коробке приходится имитировать костылями.
  • Критичные интеграции — с 1С, телефонией, платежами, складом, API партнёров, где коробочный коннектор не покрывает вашу специфику.
  • Коробка стала тормозом, а не опорой — половина рабочего времени уходит на обходные пути, а каждое обновление вендора грозит сломать ваши доработки.
  • Процесс — ваше конкурентное преимущество — то, как вы работаете с партнёрами или клиентами, и есть причина, по которой у вас покупают. Такое нельзя отдавать под ограничения чужого продукта.

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

Стоимость владения, а не цена внедрения

Главная ошибка сравнения — смотреть только на ценник запуска. Считать нужно на горизонте 2–3 лет:

  • Коробка: лицензии/подписка (растут с числом пользователей), стоимость доработок под каждое изменение, риск, что обновление вендора сломает кастомизацию, и потолок, за который вы не выйдете.
  • Заказная платформа: выше стартовые вложения (от 3 млн ₽), но фиксированная стоимость владения, код и права передаются вам по договору, развитие — по вашему приоритету, а не по роадмапу вендора.

Перелом обычно наступает там, где абонентка коробки плюс регулярные доработки за 2–3 года догоняют стоимость собственной разработки — а вы всё это время работаете в системе, которую не контролируете.

Как снизить риск: не «всё сразу», а MVP на одну роль

Даже когда решение в пользу своей платформы принято, строить её целиком за один заход — плохая идея. Мы почти всегда начинаем с MVP на одну роль — ту, где больше всего ручной работы. Это 8–12 недель и от 1.5 млн ₽ вместо «полгода и 5 млн вслепую».

Логика простая: MVP закрывает самый больной сценарий, приносит измеримый эффект (время цикла процесса обычно падает на 40–70%, доля ручных операций — до 10–20%), и уже на реальных данных видно, что достраивать дальше. Полноценная production-платформа с 3–4 ролями и интеграциями — это следующий шаг на 4–6 месяцев, а не стартовое обязательство.

Тот же принцип работает и в обратную сторону: иногда вместо платформы для первой роли достаточно Telegram-бота, который заменяет личный кабинет за 20–30% стоимости портала. Начинать стоит с самого дешёвого решения, которое закрывает боль.

Когда честный ответ — «вам не нужна разработка»

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

  • процесс типовой и хорошо ложится в Битрикс24 или amoCRM;
  • команда меньше 5–10 человек и процесс ещё меняется каждый месяц — сначала стабилизируйте его на коробке;
  • нет владельца продукта на вашей стороне, который сможет принимать решения по логике, — это риск номер один, дороже любого кода;
  • бюджета хватает только на запуск, но не на поддержку и развитие — заброшенная кастомная система хуже живой коробки.

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

Отдельный случай: готовый агрегатор вместо своей платформы

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

Правило простое: агрегатор берут, пока логика расчёта у вас стандартная. Если вам нужны продажи, остатки, оборачиваемость и рейтинг — это ровно то, что готовый сервис считает лучше и дешевле, чем любая своя разработка. Спорить с ним бессмысленно.

Упирается он в четыре вещи, и все четыре — про вашу собственную математику:

  1. Своя формула юнит-экономики. Как только в маржинальность входят транзитные затраты, кобрендинг, упаковка, возвраты по своей методике или распределение косвенных расходов — чужой сервис считает не то, что вам нужно, и «докрутить» это в нём нельзя.
  2. Связка с учётом. Агрегатор живёт отдельно от 1С. Пока цифры сверяет человек в Excel, это терпимо; когда по ним принимаются решения о закупке, расхождение между кабинетом, агрегатором и учётом становится ежедневной работой.
  3. Роли и доступы. Менеджеру по категории нужно видеть свою категорию, а не весь оборот компании. В готовых сервисах разграничение либо грубое, либо стоит как отдельный тариф на каждого пользователя.
  4. Отдача данных наружу. Если вы сами хотите отдавать отчёты клиентам или партнёрам через API или личный кабинет — чужой агрегатор для этого не предназначен, и перепродавать его вы не вправе.

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

Отдельно стоит учитывать, что подключение к маркетплейсам — это не «взять API и забрать данные»: там лимиты, асинхронные отчёты и расхождения между отчётами за один и тот же период. Разбор — в статье про лимиты и ошибки API маркетплейсов, а как устроен расчёт маржинальности — в разборе почему кабинета недостаточно.

Что в итоге

  • Считайте не «хочется своё», а «сколько стоят ограничения коробки каждый месяц».
  • Правило 30% доработок: меньше — берите коробку, больше — считайте разработку.
  • Три и более признака (роли, документы, интеграции, потолок коробки, процесс как преимущество) — заказная платформа предметна.
  • Сравнивайте стоимость владения за 2–3 года, а не цену внедрения.
  • Стартуйте с MVP на одну роль (8–12 недель, от 1.5 млн ₽), а иногда — с бота вместо портала.

Подробнее об услуге — заказная B2B-платформа и разработка SaaS-продукта. Если не уверены, коробка вам нужна или своё, — разберём процесс и посчитаем оба варианта на встрече за 60 минут.

Похожая задача в вашем бизнесе?

За 60 минут разберём вашу задачу, покажем архитектуру и оценим бюджет.

Перезвоним по вашей задаче

Оставьте номер — наберём в течение часа в рабочее время (Пн–Пт, 10:00–19:00 МСК).

Введите номер