Развитие ядер для запуска приложений за 2019 год. Часть 2

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

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

В этом направлении у меня были планы даже больше наполеоновских: постоянно вижу спрос на приложения для доставки еды либо одного ресторана, либо агрегатора типа Яндекс.Еды. Пообщавшись с несколькими заказчиками, услышал среднюю цену за приложение, которую они готовы отдать. Для доставки это в районе 50 тыс рублей, за MVP агрегатора - 100 - 200 тыс.

У меня и родилась мысль, аналогично RTPlatform для сервисов заказа услуг, сделать ядра для доставки еды и агрегатора доставок. Здесь ситуации, когда требования будут у всех индивидуальными, сильно отличающимися друг от друга, возникнуть не могло – бизнес по доставке примерно одинаковый и различия мне представлялись только в акциях, нюансах оплаты и бонусах. Подобный конструктор был бы прост в запуске, дёшев и запускался очень быстро. Для тестирования спроса мы сделали заготовки и промо-страницы для доставки (ныне уже всё) и для агрегатора ресторанов.

Тем не менее, что-то пошло не так. Оказалось, что ситуация сложнее: заказчика больше интересовала более индивидуальная реализация приложения «под себя», да и остальные детали разнились больше, чем я ожидал: отличались системы учёта, система работы курьерки.

Кроме того, есть куча конструкторов, которым платят проценты от заказов – очень выгодный, как оказалось, вариант для новых ресторанов, которым не жаль потратить процент от небольшой выручки. А для более крупных компаний даже чисто с экономической точки зрения будет удобнее разработать собственное приложение с нуля под себя, а не пользоваться нашим почти готовым универсальным продуктом.

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

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

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

Суммарно за 2 месяца рекламной кампании мы потратили только на рекламу 300 тыс рублей и получили около 200 горячих заявок от таксопарков. Казалось бы вот он успех...

Однако, "таксистам" хотелось получить продукт в аренду либо по 5 тысяч в месяц (какая-то заколдованная цифра :)), как в saas-решениях, либо разработку за 50 - 60 тысяч рублей под себя. Тогда мы просили 175 тыс, но с огромными скидками для первых клиентов.

В первый раз я подумал, что причины две:

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

Во второй раз эти "ошибки" я уже учёл, но сделал умнее. Речи об огромных бюджетах на рекламу и разработку уже не было - нарисовал красивые мокапы, и потратил 15 тыс на РСЯ и рассылку по старым лидам. При этом, цену поставил в 50 тыс за всё внедрение, как и хотели владельцы 2 года назад.

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

Впёрлись в ту же индивидуализацию, как и в случае с доставкой. Одной компании были нужны Яндекс.Карты, другой – OSM, третьи вообще работали в такой глуши, что у них и карты-то не отображались и вместо них они пользуются текстовым описанием пунктов посадки и назначения. Доплачивать за индивидуализацию никто не хотел, т.к. рассчитывали уложиться в те же 50 тыс.

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

Тут у нас было немало интересностей – чего стоят только пожелания в духе «сделайте аналог вотсапа с возможностью выдерживать 1-2 млн. подключений за сто тысяч рублей». Такое решение будет стоить по меньшей мере миллион-два – и это я ещё не учёл индивидуальный дизайн, голосовые сообщения, групповые созвоны и тд и тп.

Я разделил все обращения за TalkApp на три категории:

• Хотят сделать прямого конкурента WhatsApp, Viber или Telegram за небольшой бюджет без понимания что делать дальше.
• Хотят в готовую инфраструктуру встроить мессенджер, т.к. текущие программисты по какой-то причине не справляются.
• Хотят сделать стартап, где основная идея общение между пользователями (сервисы знакомств, соцсети и тд).

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

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

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

В 2018 году было около 10 проектов, которые планировали сделать маркетплейс для удалённых сотрудников в сфере ремонта техники. Идея у всех была примерно схожая - клиенты размещают заказ, выбирают мастера, мастер приезжает, выполняет по чеклисту работу и получает оплату.

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

Диспетчер по GPS видит где находится мастер, а мастер видит детали заявки, заносит данные по чеклисту в приложение и закрывает заявку, затем переходит к следующей. Детально я писал об этом в одной из статей в начале года. Идея была в том, что сделать похожий на Planado софт, но в коробочном виде, чтобы внедрять во внутренний контур компании.

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

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

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