Сравниваем разработку приложения с нуля и на заготовке

Денис Гордиенко, генеральный директор Bright Mobile, о плюсах и минусах разработки с нуля и на готовом решении.

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

По этому пункту готовое решение однозначно выигрывает. Хотя всё равно не следует считать, что готовое решение – это «установить и развернуть»: в любом случае потребуются какие-то доработки под идею. Например, у нас только пятая часть клиентов использует приложение в той базе, которую мы даём сначала. Мы намеренно сделали готовое решение неким фундаментом, заготовкой, которая не содержит ничего лишнего, но легко модернизируется под нужды заказчика.

Сроки разработки при заказе готового решения включают его развёртывание и доработку, хотя бы минимальную. У кого-то – только визуальные изменения, у других – добавление логики, у третьих – адаптация под собственную сферу деятельности и т.д. В среднем по больнице, это занимает 1-2 мес.

Здесь готовое решение тоже выигрывает: оно намного дешевле, чем разработка с нуля. Всё потому, что оно – как «совместная покупка». Его разработка требует крупных денежных и временных вложений, просто его продают клиенту по бросовой цене.

По моей недавней оценке за 4 года работы над своим решением мы потратили на него около двух миллионов рублей. Понятно, что сюда входит доработка, выпуск новых версий, модернизация и пр., но такой же проект с нуля вряд ли кто-то сделает меньше, чем за 500 тысяч – с учётом тестирования и отладки.

Принцип заготовки в том, что мы продаём его в разы дешевле, но можем продавать нескольким клиентам. То есть конкретный клиент выигрывает тем, что получает существенно более низкую цену, а мы тем, что можем продать один и тот же код много раз.

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

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

К тестированию MVP они относятся хорошо – вы протестировали, всё чудесно, но для уверенности инвестору важно, чтобы в вашей команде были свои разработчики. Если у вас есть хотя бы три-четыре программиста, ведущие проект, стабильная база клиентов, которые им пользуются (и особенно – если за это платят), это явный плюс. Инвесторы видят в вас готовую команду и вкладываются как в продукт, а не как в неизвестный бизнес, выстроенный на базе готового решения.

Учитывая этот факт, многие совершают типичную ошибку. Они думают, что раз инвесторам готовое решение не нравится, а они сами останавливаться на этапе тестирования не собираются, планируя развивать продукт дальше, лучше сразу взять разработку с нуля. Однако правильнее будет сэкономить, заказав готовое решение и протестировать идею на нём, экономя свои кровные вложенные в проект деньги. А к моменту выхода на инвестиции можно, если позволяет платформа, оставить готовое решение и нанять в штат программиста.

У нас за 4 года было 6 проектов со следующей ситуацией. Человек запустился на заготовке, заказав небольшие изменения под идею, вложил небольшие деньги в раскрутку. Привлёк первых пользователей, услышал обратную связь – мы доработали, а затем, на этапе поиска инвесторов, помогли клиентам найти себе в штат программистов.

Мы плавно вводим специалиста в суть работы готового решения, и, грубо говоря, передаём проект в его ведение, в течение нескольких следующих месяцев оказывая консультационную поддержку. Так клиент выходит на инвестора, имея и заготовку, и программиста в штате. Инвестор видит, что MVP-версия запускалась правильно, т.е. человек не тратит все имеющиеся у него деньги, и не будет тратить всё только на разработку, а также защищён тем, что уже не зависит от нас.

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

В подборе программиста как раз есть ещё один скрытый нюансик. Важно выяснить предоставляются ли исходники в полном объёме (то есть можете ли Вы полноценно дорабатывать свой продукт), а так же на каком стеке технологий написано решение.

Идёте на фриланс, создаёте проект: «мне нужно сделать доработки в приложении/сайте на таком-то стеке», и описываете произвольные доработки. Смотрите количество откликов: если по вашему стеку будет лишь пара-тройка ответов, у вас, скорее всего, на этапе инвестиций будут проблемы с подбором команды.

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

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

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

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

• при работе со студией прописывать в ТЗ предоставление документации, кроме исходников, чтобы вы потом не остались с кодом один на один, и следующие разработчики по крайней мере могли разобраться, что к чему;
• при найме частника передавать работу не одному специалисту, а двоим-троим, которые будут вести её параллельно.

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

Всегда нужно иметь в виду, что продвижение – это не только рекламный бюджет и оплаты работы маркетологов, но и определённые изменения работы ядра. Не стоит думать, что программисты точно так же разбираются в маркетинге, как и в коде. Не имея никаких плохих намерений, они могут упустить что-то важное просто потому, что они технари.

Для маркетинга могут потребоваться доработки, и их нужно учитывать ещё на старте. Обоснование затрат должен предоставить маркетолог, который объяснит, что и на что потратится. Доработка в любом случае понадобится как при разработке с нуля, так и при коробочном решении, но цифра может получиться разная. Главное – заранее озаботиться тем, во сколько всё это встанет. Заложить в бюджет точную сумму, конечно, не получится, но вы хотя бы будете знать, что это реализуемо и сможете выяснить хотя бы примерные траты, а на их основе решить, что же лучше стоит выбрать – разработку с чистого листа или на готовом решении.

Буду рад, если моя статья помогла сделать правильный вывод. Больше видео на тему запуска продукта можно посмотреть на моём YouTube.