В статье
Собственное приложение стоит заказывать, когда важный процесс нельзя разумно организовать существующими средствами. До этого проверьте готовый сервис, функции вашей CRM, интеграцию и небольшой внутренний инструмент. Новая программа добавляет не только удобный интерфейс, но и обязанности по доступам, обновлениям, восстановлению и развитию.
Я предлагаю проверять альтернативы на одном реальном рабочем сценарии. Формулировка «нам неудобно в таблицах» слишком широка. Формулировка «двое сотрудников одновременно меняют статус заказа, и мы не видим историю» уже позволяет сравнивать решения. Ниже — порядок выбора для собственника, который ещё не решил, нужна ли разработка вообще.
Сформулируйте минимальные условия
Опишите, кто начинает работу, какие данные получает, что должен сделать и кто использует результат. Отдельно выпишите обязательные условия: права доступа, история изменений, допустимая задержка, выгрузка данных и действия при сбое.
Разделите ограничения и предпочтения. Если без разграничения доступа пользоваться продуктом нельзя, это обязательное условие. Если команде просто привычнее другая раскладка кнопок, такой аргумент стоит сопоставить с расходами на собственный интерфейс.
Попросите участников показать сложный случай: повторный заказ, возврат, отмену или изменение документа. Демонстрация только идеальной последовательности скрывает причины, по которым готовое решение может не подойти.
Какие альтернативы проверить
Готовый сервис по подписке
SaaS — программа, которой пользуются как услугой, без разработки её основной части под себя. Это кандидат для распространённых задач: учёта заявок, записи, согласования или обмена документами. Проверять нужно не количество функций на сайте поставщика, а свой сценарий.
Уточните необходимые права, доступность выгрузки, ограничения пользователей и платные дополнения. Если нужное действие возможно только через дорогой дополнительный модуль, учитывайте его с начала сравнения. Подписка не означает отсутствия расходов на настройку и обучение.
Функции уже оплаченной CRM
Возможно, компания не использует встроенные поля, задачи, отчёты или правила назначения. Попросите показать, как существующая система решает конкретную проблему, а не предложить ещё одну общую презентацию.
Если выбор касается именно системы продаж, подробное сравнение есть в статье о готовой и собственной CRM. Здесь CRM — лишь одна из альтернатив: не каждый процесс компании нужно переносить в неё.
Интеграция действующих программ
Иногда людям удобно работать в своих системах, но неудобно переносить данные между ними. Тогда новый общий интерфейс не устраняет причину ручной работы. Нужны обмен данными, проверка соответствия полей и контроль ошибок.
Проверьте доступность нужных операций, права и ограничения. Наличие API само по себе не доказывает, что можно получить конкретный документ или изменить нужный статус. Если обмен не подтверждён, его нельзя записывать как готовую возможность в план проекта.
Таблицы, формы и шаблоны
Для небольшого устойчивого процесса может хватить общей формы, таблицы с проверками и шаблона документа. Критерий — понятная ответственность за данные, а не количество строк как универсальный порог.
Такой вариант перестаёт подходить, если нужны сложные права, обязательная история действий или работа без конфликтующих изменений. Подробности самостоятельной настройки разобраны в статье об автоматизации без программиста. Возможность собрать решение своими силами не отменяет необходимости его документировать.
No-code и low-code
Это конструкторы, в которых часть логики собирается настройками, а не обычным программным кодом. Они полезны, если доступные блоки действительно покрывают сценарий. Проверьте ограничения интеграций, историю версий, перенос данных и порядок передачи настройки другому специалисту.
Не считайте конструктор автоматически дешёвым или независимым от подрядчика. Сложная схема может зависеть от её единственного автора, а нужный объём операций — от тарифа платформы. Сравнивать нужно работающий вариант с сопровождением, а не цену первого экрана.
Небольшой скрипт или внутренний инструмент
Если задача ограничена преобразованием файла, проверкой полей или подготовкой сводки, полноценное приложение может быть лишним. Небольшая программа делает одну операцию и возвращает проверяемый результат.
Сразу определите, кто запускает её, где она хранится и как сообщается об ошибке. Скрипт на личном ноутбуке без инструкции — новая зависимость от человека. При регулярной работе ему тоже нужны резервное хранение и ответственный.
Условный пример: статус заказа вместо нового кабинета
Представим компанию, где клиенты часто спрашивают о готовности заказа. Первое предложение — разработать приложение. Но сначала стоит проверить, можно ли дать понятное уведомление или защищённую страницу статуса из существующей системы.
Если клиенту нужен только текущий этап, отдельное приложение может добавить ненужную регистрацию и поддержку. Если требуется несколько сотрудников клиента с разными правами, документы и самостоятельные изменения заказа, простой ссылки уже может не хватить. Сценарии полноценного решения разобраны в материале о личном кабинете клиента.
Пример условный. Он не доказывает, что какая-либо конкретная CRM поддерживает такую страницу. Решение принимается после проверки программы и требований к доступу.
Когда собственная разработка оправданна
Основание появляется, когда проверенные варианты не обеспечивают важный сценарий, а обходные действия обходятся дороже приемлемого решения. Например, особые роли, сложная последовательность согласований или необходимость управлять продуктом независимо от чужого набора функций.
Для сравнения требований безопасности можно использовать открытый стандарт OWASP ASVS. Он описывает проверяемые требования к веб-приложениям; это ориентир для обсуждения, а не сертификат качества выбранного сервиса и не обязательный полный перечень для каждого маленького инструмента.
Разработка не подходит, если процесс ещё не проверен, основные правила меняются вместе с каждой новой идеей или нет человека, который будет принимать продукт. При таких условиях лучше начать с ограниченного эксперимента и уточнения требований.
Сравнивайте владение и возможность выхода
Для каждого варианта запишите расходы на настройку, лицензии, работу команды, поддержку, исправления и последующий перенос. Зафиксируйте, что произойдёт при смене исполнителя или поставщика: доступна ли выгрузка, кому принадлежат учётные записи, кто хранит инструкции.
Собственный код не даёт независимости автоматически. Если только один разработчик умеет его запускать, зависимость остаётся. Готовый сервис тоже может оказаться устойчивым вариантом, если есть понятные условия доступа, экспорта и сопровождения.
Результат выбора для собственника — короткое объяснение, какие альтернативы проверены и на каком обязательном условии они не прошли. Если такого объяснения пока нет, разработку рано считать единственным выходом. Начните с инструмента Проверить, какая технология подойдёт и используйте результат как основу для разговора, а не как подтверждение всех возможностей будущей системы.