Разработка на заказ или готовое решение: как выбрать ПО для бизнеса

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

Этот материал — о бизнес-ПО для внутренних процессов: CRM, ERP, учёт, склад, HR, клиентские кабинеты и порталы для партнёров. Про сайты логика похожая, но со своей спецификой — её мы разобрали в статье «Коробочные решения: подводные камни готовых сайтов для бизнеса» и в сравнении конструктора сайтов и кастомной разработки.

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

Что такое готовое решение: коробка и SaaS

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

Коробочное ПО (on-premise, лицензия)

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

Типичные представители класса — учётные системы на платформе «1С», коробочные версии корпоративных порталов вроде «Битрикс24», серверные редакции систем документооборота. Для них сложился рынок интеграторов: внедрение 1С или внедрение Битрикс24 — это тоже вариант «готового решения», просто с профессиональной настройкой под компанию.

SaaS по подписке

SaaS (software as a service) — программа, которая работает в облаке поставщика. Клиент ничего не устанавливает: открывает браузер или приложение и платит ежемесячную или годовую подписку, обычно за каждого пользователя или за набор модулей. Обновления, серверы и резервное копирование — на стороне вендора. Пример класса — облачные CRM для отдела продаж (amoCRM, облачная редакция «Битрикс24» и аналоги), таск-трекеры, сервисы онлайн-бухгалтерии.

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

Кто обычно выбирает готовое решение

Готовое ПО — естественный выбор для малого бизнеса и для типовых функций в компании любого размера. Бухгалтерский и кадровый учёт, электронная почта, базовая CRM для небольшого отдела продаж, планирование задач, видеосвязь — эти процессы почти одинаковы в разных организациях, и вендор уже решил их лучше, чем можно сделать с нуля за разумные деньги. Крупные компании тоже используют десятки готовых систем — просто там, где процесс не отличает их от конкурентов.

Что такое разработка на заказ

Разработка на заказ (кастомная разработка, индивидуальная разработка программного обеспечения) — создание системы под конкретные процессы, данные и цели одной компании. Функции определяет заказчик, архитектуру и технологии подбирают под его нагрузку и окружение, а результат — программа, права на которую по договору переходят заказчику.

Как устроен процесс

Заказная разработка ПО проходит несколько этапов, и от их качества напрямую зависит итог:

1. Discovery и аналитика. Команда изучает процессы, пользователей, данные и ограничения, формирует цели и границы проекта. Что входит в этот этап, мы описали в статье «Как вместе с клиентом из идеи спроектировать приложение».
2. Требования и ТЗ. Функциональные и нефункциональные требования фиксируются в техническом задании или спецификации — подробнее в материале «SRS: что такое и зачем это нужно разработчикам».
3. Проектирование. Архитектура, модель данных, интеграции, прототипы интерфейсов.
4. MVP. Первая рабочая версия с ключевыми функциями, на которой сотрудники начинают работать и дают обратную связь.
5. Итерации. Система наращивает функциональность по приоритетам бизнеса. Как выбрать модель управления этим этапом, читайте в сравнении Agile и Waterfall.
6. Поддержка и развитие. Исправление ошибок, обновления зависимостей, новые функции по мере роста компании.

Кто выбирает разработку на заказ

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

Сравнение готового решения и разработки на заказ: таблица

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

Критерий	Готовое решение (коробка / SaaS)	Разработка на заказ
Срок запуска	Типично от нескольких дней (SaaS) до нескольких месяцев (внедрение крупной коробки)	Типично несколько месяцев до MVP, дальше — развитие итерациями
Стартовые затраты	Низкие или средние: лицензия либо первый платёж по подписке плюс внедрение	Высокие: аналитика, проектирование, разработка, тестирование
Стоимость владения за 3–5 лет	Растёт с числом пользователей, модулей и доработок	Основные затраты в начале, дальше — поддержка и развитие
Соответствие процессам	Компания подстраивается под логику продукта	Система повторяет процессы компании
Кастомизация	В пределах настроек и точек расширения вендора	Без ограничений со стороны продукта, ограничены только бюджетом
Интеграции	Готовые коннекторы к популярным системам, нестандартные — сложно	Любые, под ваши системы и форматы данных
Масштабирование	Обычно через более дорогой тариф или редакцию	Через архитектуру и инфраструктуру, без платы за каждого пользователя
Права на код и данные	Право использования по лицензии, кода нет	Исключительное право и исходный код — у заказчика (по договору)
Зависимость от вендора	Высокая: цены, функции и сроки жизни продукта решает вендор	Зависимость от подрядчика, снижается документацией и передачей кода
Обновления и поддержка	Выпускает вендор, в том числе изменения, которые вам не нужны	Планируете сами, оплачиваете отдельно
Безопасность и размещение данных	У SaaS — на серверах поставщика, по его стандартам	Где решите: свои серверы, выбранное облако, нужная юрисдикция
Требования импортозамещения	Нужно проверить, есть ли продукт в реестре отечественного ПО	Можно заложить российский стек и при необходимости внести программу в реестр

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

Плюсы и минусы готового ПО

Плюсы

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

Минусы

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

Плюсы и минусы разработки на заказ

Плюсы

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

Минусы

• высокие стартовые вложения — аналитика, проектирование и разработка оплачиваются до того, как система начнёт приносить пользу;
• время — до первой рабочей версии проходят месяцы, а не дни;
• риск неудачного проекта — ошибки в требованиях или выборе подрядчика стоят дорого;
• ответственность за развитие — обновления, безопасность и поддержку нужно планировать и оплачивать самостоятельно;
• зависимость от команды — без документации и передачи знаний систему трудно передать другому исполнителю;
• нужен вовлечённый заказчик — кто-то с вашей стороны должен формулировать требования и принимать решения.

Когда выбрать готовое решение?

Готовое программное обеспечение оправдано, когда процесс не отличает вас от конкурентов, а скорость и предсказуемость расходов важнее точного соответствия. Типичные сценарии:

1. Процесс типовой и регламентирован извне. Бухгалтерия, кадровый учёт, отчётность — правила задаёт законодательство, и вендор отслеживает их изменения за вас.
2. Нужно запуститься за недели. Новый отдел, новое направление, срочная замена ушедшего сервиса — время важнее идеального совпадения с процессом.
3. Бизнес небольшой или процессы ещё не устоялись. Пока компания ищет свою модель работы, заказывать под неё систему рано: требования изменятся быстрее, чем закончится разработка.
4. Коробка закрывает почти все критичные функции. Если после проверки на реальных сценариях недостаёт мелочей, которые решаются настройкой или небольшим модулем, писать своё нет смысла.
5. Нет ресурса на управление проектом разработки. Заказная разработка требует владельца продукта со стороны заказчика. Если такого человека нет и не будет, готовое решение честнее.

Когда выбрать разработку на заказ?

Разработка ПО на заказ окупается там, где процесс — часть вашего преимущества или где готовые продукты требуют столько доработок, что перестают быть «готовыми». Типичные сценарии:

1. Процесс уникален и создаёт конкурентное преимущество. Своя модель ценообразования, логистики, работы с клиентами — если вписать её в коробку, она станет такой же, как у всех.
2. Коробка требует большого объёма доработок. Когда критичных функций не хватает или каждую приходится «обходить» настройками, вы платите за лицензию и за доработки одновременно, а права на код так и не получаете.
3. Много интеграций. Система должна обмениваться данными с учётной программой, складом, оборудованием, сайтом, сервисами партнёров. Нестандартные интеграции проще и надёжнее строить в своей архитектуре, например через собственный слой API и бэкенда.
4. Рост числа пользователей делает подписку дорогой. Когда счёт за SaaS растёт быстрее, чем выручка, а горизонт использования — годы, своя система часто выигрывает по стоимости владения.
5. Жёсткие требования к данным. Персональные данные, коммерческая тайна, требования к объектам КИИ или к месту хранения — иногда проще выполнить их в своей системе, чем проверять соответствие чужой.
6. Программа станет продуктом. Если систему вы планируете продавать клиентам или партнёрам, нужен свой код и права на него. О таком сценарии — на странице о разработке SaaS.

Сколько на самом деле стоит готовое решение: скрытые расходы

Главная ловушка выбора — сравнивать цену подписки с ценой разработки. Это сравнение несопоставимых величин: подписка — лишь одна строка в расходах на готовое решение. Вот что обычно в неё не попадает:

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

Как посчитать TCO на 3–5 лет

Стоимость владения (TCO, total cost of ownership) — сумма всех затрат на систему за выбранный срок. Для готового решения формула выглядит так: лицензии или подписка × число пользователей × срок + внедрение + доработки + интеграции + обучение + поддержка + стоимость выхода. Для заказной разработки: аналитика и разработка + поддержка и развитие × срок + инфраструктура × срок + стоимость передачи и документации. Методика оценки разработки подробно разобрана в статьях «Из чего состоит оценка проекта для заказной разработки» и «Как считают стоимость веб-сервиса».

Условный пример — цифры придуманы для иллюстрации расчёта и не отражают рыночных цен. Компания выбирает систему для отдела продаж и сервиса. Вариант А — SaaS с подпиской 1 500 ₽ за пользователя в месяц. Вариант Б — своя система.

Статья затрат	SaaS, 50 пользователей, 3 года	Своя система, 3 года
Подписка: 1 500 ₽ × 50 польз. × 36 мес.	2 700 000 ₽	—
Внедрение и настройка	600 000 ₽	—
Доработки под процессы	900 000 ₽	—
Интеграции	500 000 ₽	—
Обучение	150 000 ₽	—
Аналитика и разработка (включая интеграции)	—	5 000 000 ₽
Поддержка и развитие: 800 000 ₽ × 3 года	—	2 400 000 ₽
Инфраструктура: 200 000 ₽ × 3 года	—	600 000 ₽
Итого	4 850 000 ₽	8 000 000 ₽

При таких вводных на трёх годах и 50 пользователях выигрывает SaaS. Теперь поменяем два параметра: компания выросла до 150 пользователей, горизонт — пять лет. Подписка составит 1 500 ₽ × 150 × 60 мес. = 13 500 000 ₽; вместе с разовыми расходами на внедрение, доработки, интеграции и обучение (2 150 000 ₽) и повторными доработками после обновлений (условно 400 000 ₽) — 16 050 000 ₽. Своя система за пять лет: 5 000 000 ₽ разработки + 4 000 000 ₽ поддержки (800 000 ₽ × 5) + 1 000 000 ₽ инфраструктуры (200 000 ₽ × 5) + 500 000 ₽ на расширение серверов под рост нагрузки = 10 500 000 ₽.

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

Кому принадлежит код и данные: права, договор и зависимость от вендора

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

Права на заказной код

Базовое правило задаёт статья 1296 Гражданского кодекса РФ: исключительное право на программу для ЭВМ, созданную по договору, предметом которого было её создание (то есть по заказу), принадлежит заказчику, если договором не предусмотрено иное. При этом исполнитель, если договор не говорит иного, вправе использовать такую программу для собственных нужд на условиях безвозмездной простой (неисключительной) лицензии в течение всего срока действия исключительного права.

Из этого следуют практические выводы. «Если договором не предусмотрено иное» — значит, условия договора важнее общего правила, и их стоит прочитать внимательно. Что рекомендуем прописать явно:

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

Права при коробке и SaaS

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

Vendor lock-in и стратегия выхода

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

• экспорт данных — проверьте на тестовом аккаунте, что выгрузка полная и в открытых форматах (CSV, JSON, XML), включая историю и вложения;
• API — документированный и доступный на вашем тарифе, чтобы интеграции можно было перенастроить на другую систему;
• условия расторжения — срок уведомления, порядок возврата и удаления данных, переходный период;
• место хранения данных — в какой стране и у какого провайдера физически находятся серверы.

У заказной разработки свой вариант lock-in — зависимость от подрядчика. Лечится она тем же принципом: код в репозитории заказчика, актуальная документация, автоматизированные сборка и тесты, регулярная передача знаний вашей команде. Если подрядчик против этих условий — это тревожный сигнал.

Импортозамещение: как оно влияет на выбор

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

• Реестр российского ПО. Единый реестр российских программ для ЭВМ и баз данных ведёт Минцифры, порядок установлен постановлением Правительства РФ № 1236 от 16.11.2015. Наличие продукта в реестре важно прежде всего для госзакупок и для ряда организаций с государственным участием.
• Критическая информационная инфраструктура (КИИ). Для значимых объектов КИИ Федеральный закон от 07.04.2025 № 58-ФЗ установил переход на отечественное ПО до 1 января 2028 года (Интерфакс). Отдельно постановление Правительства РФ № 1912 от 14.11.2023 регулирует переход субъектов КИИ на доверенные программно-аппаратные комплексы с предельным сроком 1 января 2030 года.

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

Гибридный путь: коробка + доработки, low-code и поэтапный переход

Выбор «разработка на заказ или готовое решение» на практике редко бывает бинарным. Многие компании комбинируют подходы, и это часто самый рациональный вариант.

Коробка + кастомные модули и интеграции

Типовую часть процесса закрывает готовая система, а то, что отличает компанию, разрабатывается отдельными модулями и связывается с коробкой через API. Например, учёт ведётся в стандартной учётной системе, а расчёт уникального ценообразования, клиентский кабинет или складская логика — в собственном сервисе. Так вы не переплачиваете за то, что уже решено рынком, и сохраняете права на то, что действительно ваше. Такой подход лежит в основе многих проектов автоматизации CRM и ERP.

Low-code и no-code для прототипа

Low-code и no-code платформы позволяют собрать рабочий инструмент без классической разработки: формы, базы данных, простые сценарии автоматизации. Это хороший способ проверить процесс и требования, прежде чем вкладываться в полноценную систему, или быстро закрыть внутреннюю задачу с небольшим числом пользователей. Ограничения — сложная логика, нагрузка и зависимость от платформы. Подробнее — на странице no-code разработки.

MVP своего решения и поэтапная замена

Распространённая траектория роста выглядит так: старт на SaaS → рост и накопление требований → своё ядро для ключевого процесса → поэтапный перенос остальных функций. MVP собственной системы закрывает самый болезненный участок, а остальное продолжает работать в коробке, пока не придёт его очередь. Как определить минимальный объём первой версии, мы писали в статье «MVP: от концепции до создания минимально жизнеспособного продукта»; заказать такую версию можно в рамках разработки MVP.

Как выбрать между готовым ПО и разработкой на заказ: алгоритм из 6 шагов

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

1. Опишите процессы. Нарисуйте, как работа идёт сейчас и как должна идти. Отметьте процессы, которые дают вам преимущество, и процессы, которые у всех одинаковые.
2. Составьте список критичных функций и проверьте 2–3 готовых продукта. Не по презентации, а на демо-стенде с вашими реальными сценариями. Посчитайте, какую долю критичных функций каждый закрывает без доработок.
3. Посчитайте TCO на 3–5 лет по обоим путям. С учётом роста числа пользователей, доработок, интеграций и стоимости выхода.
4. Оцените интеграции и данные. С какими системами нужен обмен, в каких форматах, кто владеет данными и где они будут храниться.
5. Проверьте юридические и регуляторные требования. Права на код и данные, реестр российского ПО, требования к объектам КИИ, обработка персональных данных по 152-ФЗ.
6. Решите, нужен ли пилот или MVP. Если после пяти шагов картина не очевидна, запустите пилот готового решения на одном подразделении или закажите MVP своей системы для самого критичного процесса — и сравните на практике.

Чек-лист вопросов к вендору и к подрядчику

Вопросы к вендору готового решения:

• Как выгрузить все данные, включая историю и вложения, и в каких форматах?
• Как менялись тарифы за последние годы и как вы уведомляете клиентов об изменениях?
• Какие доработки возможны и что с ними происходит после обновления продукта?
• Есть ли документированный API, и входит ли он в наш тариф?
• Где физически хранятся данные и кто имеет к ним доступ?
• Есть ли продукт в реестре российского ПО (если это важно для вас)?
• Что происходит с данными после окончания подписки?

Вопросы к подрядчику по заказной разработке:

• Переходит ли к нам исключительное право на код, и в какой момент?
• Будет ли код с первого дня в нашем репозитории?
• Какую документацию мы получим и как будет организована передача знаний?
• Как устроены оценка, приёмка и порядок изменений требований?
• Какие сторонние библиотеки и сервисы вы используете и на каких лицензиях?
• Как будет организована поддержка после запуска и сколько она стоит?
• Можно ли начать с discovery-этапа и MVP, чтобы проверить работу вместе?

Сроки и стоимость разработки на заказ

Универсальной цены у заказной разработки нет: бюджет определяет объём работы, а не название системы. Основные факторы:

• объём и сложность функций — число ролей, сценариев, отчётов, правил расчёта;
• интеграции — их количество и то, насколько документированы системы, с которыми нужен обмен;
• платформы — только веб, или ещё мобильные приложения для сотрудников и клиентов;
• требования к нагрузке, безопасности и надёжности — от них зависит архитектура и объём тестирования;
• миграция данных — перенос из старых систем бывает отдельным проектом;
• состав команды — аналитики, дизайнеры, разработчики, тестировщики, DevOps.

Типично первая рабочая версия внутренней системы появляется через несколько месяцев, а развитие продолжается итерациями. Точную стоимость подрядчик называет после анализа требований — оценке «по телефону» без discovery доверять не стоит. На бюджет влияет и модель договора: фиксированная цена за согласованный объём или оплата фактического времени команды. Как выбрать между ними — в статье «Fixed price или Time and Material: как выбрать модель». Пример того, из чего складывается проект конкретной системы, — в материале о разработке CRM-системы с нуля.

Как YuSMP Group подходит к выбору: купить или разработать

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

Часто задаваемые вопросы

Что дешевле — готовое решение или разработка на заказ?

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

Можно ли доработать готовое ПО под свои процессы?

Да, у большинства коробочных и SaaS-систем есть настройки, модули расширения, API и маркетплейсы приложений. Ограничения задаёт сам продукт: доработки возможны только в тех местах, которые предусмотрел вендор, а после крупных обновлений их иногда приходится переделывать. Если доработки затрагивают ядро логики системы, стоит сравнить их стоимость с разработкой своего решения.

Кому принадлежат права на программу, разработанную по заказу?

По статье 1296 ГК РФ исключительное право на программу, созданную по договору заказа, принадлежит заказчику, если договором не предусмотрено иное. При этом исполнитель, если договор не говорит иного, вправе использовать программу для собственных нужд на условиях безвозмездной простой лицензии. Поэтому в договоре стоит прямо прописать передачу исключительного права, исходного кода, документации и доступов к репозиторию.

Что такое vendor lock-in и как его избежать?

Vendor lock-in — зависимость от поставщика, при которой сменить систему слишком дорого или сложно: данные хранятся в закрытом формате, процессы завязаны на уникальные функции, интеграции построены на собственном API вендора. Снизить риск помогают выгрузка данных в открытых форматах, документированные API, условия расторжения в договоре и план выхода, составленный ещё до внедрения.

Чем SaaS отличается от коробочного ПО?

Коробочное ПО обычно покупают по лицензии и устанавливают на свои серверы: компания сама отвечает за инфраструктуру и обновления, но контролирует данные. SaaS работает в облаке поставщика по подписке: обновления и инфраструктура на вендоре, запуск быстрее, но данные хранятся у поставщика, а стоимость растёт вместе с числом пользователей и модулей.

Сколько времени занимает разработка на заказ?

Зависит от объёма функций, интеграций и платформ. Типично первая рабочая версия (MVP) внутренней системы занимает несколько месяцев, а полнофункциональное решение для крупной компании развивается от полугода и дольше. Точный срок подрядчик называет после анализа требований и оценки проекта.

Можно ли начать с готового решения, а потом перейти на своё?

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

Нужно ли заказное ПО вносить в реестр российского ПО?

Только если этого требуют условия работы: например, вы планируете продавать программу госзаказчикам или вашей организации нужно подтверждать использование отечественного ПО. Для внутреннего использования коммерческой компанией включение в реестр не обязательно. Обладатель исключительного права на заказную программу может подать заявку на включение в реестр самостоятельно.

Подойдёт ли low-code вместо разработки на заказ?

Для простых внутренних процессов, прототипов и автоматизации отдельных задач — часто да: low-code и no-code позволяют собрать рабочее решение быстрее и дешевле. Для сложной логики, высоких нагрузок, нестандартных интеграций и продуктов, которые будут продаваться клиентам, возможностей платформы обычно не хватает, и стоит планировать переход на полноценную разработку.

Вывод

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

Выбирайте готовое решение или SaaS, если процесс типовой, запуститься нужно быстро, бюджет ограничен, а проверка на реальных сценариях показала, что продукт закрывает почти все критичные функции. Заранее проверьте выгрузку данных и условия выхода.

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

Выбирайте гибрид, если не уверены: оставьте типовое в готовых системах, а для ключевого процесса начните с пилота или MVP своего решения. Так вы проверите гипотезу на практике и не переплатите ни за лишнюю разработку, ни за годы чужой подписки.