Этот вопрос всплывает почти на каждом проекте. Клиент находит в маркетплейсе приложение, которое вроде бы делает нужное, и спрашивает: берём или пишем своё. Ответ «зависит» никого не устраивает, поэтому расскажу, от чего именно зависит. У меня есть четыре вопроса, которые я задаю до того, как начинаю сравнивать функциональность и цену, — и почти всегда решение становится очевидным уже после них.
Первый вопрос: как часто будут меняться требования
Это главный критерий, и он важнее цены. Если процесс стабильный и меняется раз в пару лет — берём готовое, оно закроет задачу и не потребует внимания. Если требования будут ползти каждый месяц, потому что бизнес растёт и вы сами ещё не до конца понимаете финальную схему, — готовое решение станет клеткой.
Механика простая. Покупное приложение делает то, что задумал его автор, и настраивается в тех пределах, которые он предусмотрел. Пока ваши хотелки внутри этих пределов, всё прекрасно. Как только вам нужен шаг в сторону, начинается торг с чужим бэклогом: написать разработчику, попросить, подождать, услышать «в планах».
Поэтому я честно спрашиваю клиента: это у вас процесс или эксперимент. Если люди сами формулируют «пока попробуем, потом поймём» — значит требования будут меняться, и надо либо брать что-то предельно простое и не жалко заменяемое, либо сразу собирать своё. Люди приходят с представлением о задаче, которое всё равно приходится пересобирать по ходу дела, и это нормально.
Второй вопрос: насколько вы становитесь зависимы
Покупая приложение, вы получаете не только функциональность, но и зависимость. От того, что автор продолжит его развивать. От того, что он не сменит модель подписки. От того, что при обновлении платформы он успеет выпустить совместимую версию. Всё это находится вне вашего контроля, и повлиять вы на это не можете.
Отдельно смотрю, где живут данные и доступы. Если решение гоняет вашу клиентскую базу через свой сервер, это уже не просто удобная кнопка, а вопрос безопасности и переговорной позиции. Я вообще считаю, что ключи и доступы — собственность компании, и писал об этом в разборе почему доступы должен держать собственник.
Своя разработка зависимость снимает, но не бесплатно: теперь вы сами отвечаете за совместимость с обновлениями платформы и за то, чтобы был человек, который в этом коде разбирается. Это не аргумент против — это просто честная цена независимости, которую надо заложить в решение заранее.
Третий вопрос: сколько стоит владение, а не покупка
Цена приложения на витрине — это только вход. Считать надо владение на горизонте нескольких лет: подписка или продления, оплата доработок под себя, время интегратора на настройку, время сотрудников на обучение. Нередко выходит, что «дешёвое» решение за пару лет догоняет по деньгам собственную разработку и при этом остаётся негибким.
У своей разработки структура затрат другая: больше на старте, меньше потом, но появляется постоянная строчка на поддержку. Тут важно не обманывать себя нулём в этой строчке. Код без сопровождения — это отложенная проблема, которая проявится в самый неудобный момент, обычно после крупного обновления.
Есть и третий вариант, про который часто забывают: собрать нужное штатными средствами платформы. Смарт-процессы, роботы, бизнес-процессы и поля закрывают заметную часть задач без единой строчки кода. Я специально разбирал, что можно собрать в Битрикс24 без разработчиков — прежде чем платить кому-то, стоит проверить этот путь.
Почему сравнение по списку функций обманчиво
Обычно выбор начинают с таблицы: у этого решения есть такая галочка, у того нет. Способ понятный, но он почти всегда врёт. Наличие функции ничего не говорит о том, как она работает на вашем объёме данных, в вашей структуре и в ваших руках. Одна и та же строчка в описании у двух продуктов может означать совершенно разные вещи.
Гораздо полезнее взять два-три своих реальных сценария и пройти их целиком на демо-версии. Не «есть ли интеграция», а «проведи мою типовую сделку от заявки до оплаты и посмотри, где заедает». За полчаса такой проверки узнаёшь больше, чем за неделю чтения описаний, и сразу видно, где придётся допиливать.
И третье: спросите себя, что будет с этим решением через год работы, когда данных станет в разы больше, а сотрудников прибавится. Инструмент, который прекрасно ведёт себя на десяти записях, иногда становится неудобным на тысячах. Проверить это заранее сложно, но хотя бы задать вопрос автору решения — совершенно нормально.
Четвёртый вопрос: кто будет это поддерживать
У готового решения поддержка формально есть — у вендора. Вопрос в её реальном качестве: как быстро отвечают, есть ли живой контакт, чинят ли или отписываются. Это проверяется до покупки: напишите им с предпродажным вопросом и посмотрите, что и когда вам ответят. Скорость и внятность ответа на этом этапе многое говорят о том, что будет потом.
Смотрю также на возраст решения и на то, сколько компаний им пользуется. Не потому что популярность — гарантия качества, а потому что решение, которое живёт годами и регулярно обновляется, вряд ли бросят завтра. Свежий продукт от неизвестного автора может оказаться прекрасным, но это ставка, и делать её на критичном участке процесса я не стану.
У своей разработки поддержка — это конкретные люди. Либо ваш штатный специалист, либо подрядчик. Здесь важно письменно зафиксировать, где лежит код, кто имеет к нему доступ и что происходит, если вы расстаётесь. Это скучные вопросы, которые никто не любит задавать на старте, и ровно они спасают потом.
Как это выглядит на практике
Мой рабочий алгоритм такой. Сначала пытаюсь закрыть задачу штатными средствами — это самый дешёвый и самый живучий вариант. Если не выходит, смотрю маркетплейс: есть ли зрелое решение, которое покрывает большую часть требований и не требует пыток при настройке. И только если и там пусто или всё слишком негибко, иду в разработку.
Отдельно проговариваю с клиентом главный риск покупного пути: приложение может перестать обновляться. Это происходит не громко, а тихо — автор потерял интерес, компания сменила фокус, продукт стал непрофильным. Однажды после обновления портала оно просто перестаёт работать, и вы остаетесь с процессом, который на нём держался.
Ещё одно наблюдение из практики: решение проще принимать, когда вы заранее знаете, как будете с него слезать. Если понятно, что данные при необходимости выгружаются, а процесс можно перенести, любой выбор перестаёт быть фатальным.
Поэтому там, где решение стоит в сердце процесса, я склоняюсь к своему; там, где это вспомогательная функция, беру готовое и не переживаю. И почти всегда начинаю от самого простого варианта, а не от красивого: сначала минимальная работающая версия, потом развитие по факту. Помочь выбрать этот путь и посчитать владение — часть наших работ по внедрению и доработкам.
Частые вопросы
Когда лучше купить готовое приложение в маркетплейсе?
Когда процесс стабильный, требования меняются редко, а функция вспомогательная. Готовое решение даёт быстрый старт и понятную цену входа, а развитие остаётся заботой вендора.
Когда оправдана своя разработка?
Когда требования часто меняются, решение стоит в сердце ключевого процесса или нужна независимость от чужих планов развития. Взамен вы берёте на себя совместимость с обновлениями и поддержку.
Что делать, если купленное приложение перестало обновляться?
Заранее оценивать этот риск: смотреть возраст решения, регулярность обновлений и качество поддержки, а на критичных участках предпочитать штатные средства платформы или собственную разработку с доступом к коду.