Простой гайд для предпринимателей: купить готовое решение или уйти в собственную разработку?

Вечный вопрос, который терзает предпринимателей: взять готовую ИТ платформу и на ней сделать продукт или разработать все самому? В этой статье подробно расскажу про каждый из путей.

За 20 лет в ИТ я побывал в роли заказчика, аутсорсера и даже собственника готового решения. Поэтому когда в очередной раз услышал вопрос: “Собственная разработка или SaaS?”, решил, что пора расставить все точки над i в статье.

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

а) Использовать white label (готовое) решение за 500 т.р. + процент от оборота
б) Разработать собственное приложение в десять раз дороже

Какой вариант выбрать? И какие вопросы стоит задать, чтобы выбрать оптимальный?

Традиционно выделяют всего две:

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

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

Чтобы нематериальные активы имели какую-то ценность при продаже, они должны быть в собственности компании и стоять на балансе. Нет собственного ПО на балансе? Извините, но тогда покупать нечего.

Вывод: готовое решение не подходит, если есть планы по продаже компании.

Давайте поставим себя на место разработчика white label продукта. Как правило основной заработок идет на предоставлении готового решения за абонентскую плату. Хорошо ли, если придет клиент, который будет платить абонентку и дополнительно заказывать платные доработки? На первый взгляд, лучше и быть не может. Но есть нюанс.

Большое количество доработок под одного, пусть даже самого крупного и любимого клиента, неизбежно будет мешать разработке основного коробочного продукта. Это усложнит поддержку, расфокусирует команду и может привести к взаимному недовольству.

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

Вывод: если готовое решение соответствует идеалу почти 100% - это отличный выбор. В противном случае есть риск столкнуться с проблемами уже через несколько месяцев.

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

Вывод: для проверки гипотез лучше взять готовое, но гибкое решение.

Важно на берегу убедиться, что вы сможете безболезненно съехать с выбранного решения.

Как минимум, должна быть возможность забрать все ваши данные в удобном формате. Как максимум - копию продукта без права распространять её кому-либо ещё.

Помните историю со Slack? Они ушли из России и попутно заблокировали доступ некоторым компаниям. Многим это парализовало внутреннюю коммуникацию. Ситуация в которой лучше не оказываться.

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

Как-то раз мы сами инициировали разработку небольшого (как тогда казалось) приложения на пару месяцев и 600 т.р. Но суровая реальность и разгулявшийся аппетит умножили сроки и бюджеты в несколько раз.

Если разработчик сказал вам, что на разработку нужно 5 млн., смело умножайте бюджет на два. Ведь в процессе наверняка появятся доработки, а какие-то решения придется пересматривать.

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

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

В итоге пришли к такому плану:

• Ускорить запуск, взяв за основу готовое решение. На нем получить опыт, протестировать гипотезы, набить шишки.
• Через пару месяцев после запуска начать прорабатывать ТЗ для собственной разработки. Уже с учетом полученного опыта.