Разработка ПО на заказ начинается там, где стандартная система перестаёт поддерживать реальную работу компании. Менеджеры переносят статусы в таблицы, склад сверяет остатки вручную, документы собираются из нескольких источников, а руководитель получает данные с опозданием. В такой ситуации новый интерфейс сам по себе не поможет: нужно разобраться в процессе, определить источник данных и только затем проектировать программу.
Headline ведёт такие проекты полным циклом: от постановки задачи и разработки до деплоя, мониторинга 24/7 и дальнейшего развития. Система может работать On-Premise, внутри инфраструктуры заказчика. Это особенно важно для клиентских баз, учётных данных и документов, которые компания не хочет передавать внешней облачной платформе.
Когда разработка ПО на заказ оправдана
Собственная система нужна не каждому бизнесу. Если процесс типовой и готовый продукт покрывает его без постоянных обходов, разумнее внедрить коробку и не оплачивать создание уже существующих функций. Заказная разработка становится обоснованной, когда особенности работы напрямую влияют на выручку, скорость отгрузки, качество учёта или стоимость операции.
Характерный признак: сотрудники формально используют купленную программу, но важные решения принимают в чатах и Excel. Причина обычно не в сопротивлении людей, а в том, что система не учитывает нужные роли, исключения и связи. Например, CRM не знает об объектах и бронях, склад не видит обещанный клиенту срок, а портал не получает актуальные остатки из 1С.
- У компании уникальный цикл сделки, производства или обслуживания.
- Несколько систем хранят разные версии одного и того же факта.
- Для работы нужны интеграции с 1С, площадками, телефонией или внутренними сервисами.
- Данные должны храниться в инфраструктуре заказчика.
- После запуска нужен один ответственный за код, серверы и мониторинг.
До начала проекта важно назвать цену существующей проблемы. Это может быть потерянная сделка, задержка отгрузки, часы ручной сверки или невозможность получить достоверный отчёт. Такой ориентир помогает выбрать первый модуль и не превращать проект в бесконечный список пожеланий.
Коробка, готовый продукт или собственный код
Выбор технологии следует делать после разбора процесса. Коробка подходит для стандартной воронки, базового склада или типового документооборота. Она быстрее запускается и обычно дешевле на старте. Ограничения становятся проблемой, когда ради каждого исключения команда создаёт дополнительную таблицу или покупает модуль, который всё равно не связывает данные.
Иногда вместо проекта с нуля подходит готовый отраслевой продукт. Например, КонтрактПРО формирует договоры, счета и акты из единого источника реквизитов. Один договор по шаблону занимает 2–5 минут вместо 20–40, а пакет документов 5–15 минут вместо 1–2 часов. Эти показатели относятся к конкретному продукту и не переносятся автоматически на другие процессы.
Собственный код выбирают, когда правила компании невозможно уложить в стандартную модель без потери смысла. Тогда разработка ПО под ключ охватывает роли, статусы, интеграции, журнал действий, инфраструктуру и сценарий поддержки. Подробнее о частном случае можно прочитать в материале про разработку CRM на заказ.
Как проект проходит путь от процесса до продакшена
На первом этапе команда описывает один рабочий поток: кто создаёт запись, откуда берутся данные, кто имеет право менять статус и какой результат считается завершением операции. Здесь же фиксируют исключения. Если правила не определены, программа лишь перенесёт прежние споры в новый интерфейс.
Затем выбирают минимальный функциональный срез. Для узкой гипотезы возможен формат MVP за 14 дней. Речь идёт об одном сценарии с живыми пользователями, а не о полной ERP или CRM для всей компании. По итогам пилота принимают решение: развивать решение, изменить подход или взять готовый продукт.
- Разобрать текущий процесс и определить владельца результата.
- Зафиксировать роли, данные, интеграции и критерии готовности.
- Выбрать рамку первой версии и явно перечислить то, что в неё не входит.
- Разработать и развернуть систему в согласованной инфраструктуре.
- Провести пилот на реальных операциях и собрать наблюдения.
- Организовать мониторинг, резервные копии и очередь развития.
Инфраструктура проектируется вместе с приложением. Иначе на момент релиза выясняется, что нет безопасного доступа, резервного копирования или ответственного за сервер. Для систем, которые работают внутри компании, полезны материалы про обслуживание серверов и On-Premise.
Что показывает практика разработки
В проекте для «Мегаполис-Недвижимость» работали 25 риелторов и обрабатывалось более 50 объектов в месяц. Раньше специалисты тратили около двух часов в день на ручное обновление Avito и ЦИАН, из-за чего возникал риск двойных продаж. За четыре месяца была создана CRM с единой базой объектов, канбаном, документами, финансами, аналитикой и интеграциями. Время на сделку сократилось на 30%. Подробности собраны в кейсе CRM для недвижимости.
Этот пример показывает важный принцип: результат дала не отдельная кнопка, а связность процесса. Статус объекта, история цены, бронь и публикации перестали жить независимо. Мобильное приложение на React Native позволило загружать фотографии с осмотра прямо в систему. При этом цифры кейса характеризуют именно этот проект и не являются универсальным обещанием для любой CRM.
В производственном проекте система со складом и заказами автоматизировала около 80% рутины. Для HoReCa создано On-Premise-решение, которое сократило рутинные операции на 60%. Эти проекты отличаются по предметной области и стеку, но объединены одним подходом: сначала рабочий процесс, затем подходящий программный слой.
Основные риски заказной разработки
Самый дорогой риск связан с неопределённым объёмом. Формулировка «сделать удобнее» не даёт критерия приёмки. Нужны наблюдаемые сценарии: заказ прошёл без ручной сверки, бронь не дублируется, документ собирается из утверждённых реквизитов. Чем точнее критерий, тем проще управлять приоритетами.
Второй риск возникает на стыке подрядчиков. Разработчик отвечает за приложение, хостер за виртуальную машину, специалист по 1С за обмен, но никто не отвечает за итоговую операцию. Модель полного цикла уменьшает число таких разрывов, поскольку код, деплой и эксплуатация находятся в одной очереди.
Третий риск проявляется после релиза. Пользователи находят исключения, меняются правила и появляются новые интеграции. Без владельца продукта и понятной очереди система постепенно отстаёт от бизнеса. Поэтому сопровождение после запуска стоит планировать до первой публикации.
Наконец, опасно начинать с полной замены всех систем. Узкий пилот позволяет проверить ключевое правило на живых данных и сохранить возможность отступить. Если же компания уже зависит от старого приложения, нужен аудит и поэтапная модернизация устаревшего ПО.
Что подготовить к первой встрече
Полное техническое задание не требуется. Полезнее показать один реальный пример операции: заявку, заказ, сделку или пакет документов. Нужно отметить, где появляются ручные переносы, кто принимает решение и какая система сейчас считается источником правды. Отдельно стоит перечислить обязательные интеграции и требования к размещению данных.
Такая подготовка позволяет быстро понять, требуется ли заказная разработка, готовый продукт или настройка уже используемой системы. Она же помогает оценить, можно ли начать с функционального MVP или проект сразу затрагивает несколько критичных участков.
Частые вопросы
Всегда ли собственная система лучше коробки?
Нет. Для типового процесса коробка обычно выгоднее. Собственный код имеет смысл, когда ограничения готового решения регулярно создают ручную работу, ошибки или потерю данных.
Можно ли начать с небольшой версии?
Да. Один функциональный сценарий можно выделить в MVP и проверить на реальных пользователях. Полная ERP или CRM для большой команды в двухнедельный формат не входит.
Где будут храниться данные?
Систему можно развернуть On-Premise, в инфраструктуре клиента. Облачный вариант также возможен, если его выбирает заказчик.
Берёте ли вы проект после другой команды?
Да. Сначала проводится аудит кода и инфраструктуры, затем организуется плавный переход без обязательного переписывания всей системы.
Кто отвечает за систему после релиза?
В полный цикл входят серверы, мониторинг 24/7 и развитие функционала. На стороне клиента нужен владелец, который определяет бизнес-приоритеты.
Чтобы обсудить проект, напишите на welcome@headln.ru. В письме достаточно описать процесс, главное узкое место, используемые системы и требования к размещению данных.