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

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

Рядом: под ключ или своя команда, сколько стоит внедрение AI и как устроена архитектура решения.

Сравнение по существу

Как считать, а не спорить

Спор «дороже или дешевле» решается арифметикой, и её стоит проделать до разговора с поставщиками. Считать надо стоимость владения на том горизонте, на котором вы реально собираетесь этим пользоваться.

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

Две поправки. Первая: сравнивать надо на одном горизонте, и горизонт назвать честно. На год почти всегда дешевле готовое. На пять лет картина часто меняется. Вторая: в стоимость своего входит не только разработка, но и то, что систему нужно будет кому-то поддерживать, и этот пункт пропускают чаще всего.

Пять вопросов, которые дают ответ

1. Насколько ваш процесс похож на чужой? Бухгалтерия, почтовые рассылки, учёт обращений в малом бизнесе это стандарт, и своё здесь почти никогда не оправдано. Если же процесс и есть ваше отличие, готовое будет мешать каждый день.
2. На какой срок вы это берёте? Проверка гипотезы и система на годы это разные решения, и ошибка здесь дороже всех остальных.
3. Можно ли выносить ваши данные наружу? В части отраслей ответ определяется не вами, и тогда выбор сделан до его обсуждения.
4. Сколько систем придётся связать? Одна-две связываются штатными средствами. Когда их пять и данные должны ходить между ними без ручной работы, склейка готовых начинает стоить дороже своего.
5. Кто будет это поддерживать? Своё без ответа на этот вопрос превращается в систему, которую боятся трогать.

Третий ответ: собрать из обоих

Противопоставление устарело, и на практике чаще всего выигрывает сочетание. Стандартные части берутся готовыми, а своим пишется то, что вас отличает.

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

При таком сочетании важно с самого начала знать, где проходит граница, и держать её. Иначе через год окажется, что уникальная логика расползлась по настройкам трёх чужих сервисов, и переносить её некуда.

Что изменилось за последние годы

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

Чего они не изменили: архитектуру, понимание процесса и ответственность за решения. Ускорилось написание, а не выяснение того, что надо написать, а именно второе и определяет срок в большинстве проектов. Поэтому обещание «теперь своё делается вдвое быстрее» стоит проверять вопросом, в какой именно части ускорение.

Три мифа

• «Своё слишком дорого». Иногда да, а иногда разница исчезает на третий год подписки. Пока не посчитана стоимость владения на вашем горизонте, утверждение непроверяемо в обе стороны.
• «Своё слишком долго». Целиком долго, первый работающий кусок нет. Правильный вопрос не «когда всё», а «когда первая часть начнёт приносить пользу».
• «Своё сложно поддерживать». Зависит от того, оставили ли вам документацию, тесты и понятный код. Это условие договора, а не свойство подхода, и его надо записывать.

Признаки, что пора менять решение

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

Как я помогаю выбрать

Практика с 2004 года, проекты для заказчиков в 14 странах. Я не перепродаю платформы и не получаю от поставщиков ничего за рекомендацию, поэтому вывод «берите готовое и не начинайте разработку» для меня обычный результат работы.

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

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