No-code подход в мобильной разработке: будущее или мелкая ниша?
Меня зовут Алексей Жилин, я основатель агентства мобильной разработки SMD Agency, а также сооснователь стартапа Wiby, размышления о котором и натолкнули меня на написание этой статьи. Wiby - это сервис, в котором рестораны и доставки еды могут получить нативное мобильное приложение с бэк-офисом и интеграциями с основными CRM этой отрасли для своего ресторана или сервиса доставки еды. Вместо многомиллионного бюджета на разработку и дальнейшую поддержку своего приложения, наш сервис предлагает подписку от 4900 рублей в месяц. Мы совсем недавно начали свою деятельность и целью этой заметки вижу рассказать свои наблюдения и получить обратную связь от заинтересованной аудитории.
Существующие решения на рынке
Мысли о реализации подобного решения пришли мне в голову достаточного давно из опыта в аутсорсинговом бизнесе: множество региональных компаний приходят с очень похожими запросами и, узнав примерную стоимость, отказываются от реализации проекта по понятным причинам. В редких случаях все же решаются на предложение с низким бюджетом до 1 млн. рублей - результат в лучшем случае позволяет сделать заказ и совершить покупку, но качественным мобильным приложениям это, как правило, назвать нельзя. Шеринговая модель, как нам казалось, напрашивается. Нужно сказать, что идея не новая, аналогичные решения уже давно и относительно успешно существуют на рынке. Приведу в пример те, которые нравятся лично мне:
Napsy - более универсальная модель, для ecommerce в целом.
Loyaltyplant - больше упор на систему лояльности, но много интересных клиентов в нашей нише.
Рестомания - приложение и бэк-офис очень неплохие, много нужных сопутствующих продуктов, но модель отличается от нашей - процент с заказа и оффер включает в себя еще и доставку. Это скорее прямой конкурент агрегаторов, чем SaaS.
Общий сценарий работы с нашим и аналогичными сервисами выглядит следующим образом: клиент регистрирует аккаунт, вносит контент своего приложения (товары, акции, статичная информация), при необходимости запрашивает интеграции с внутренними системами своей компании, оплачивает выбранный тариф и приложение публикуется в Play Google и AppStore. Все обновления и фиксы выпускаются автоматически для всех подключенных к сервису компаний. Заказы поступают либо в личный кабинет сервиса, либо в CRM с которой проведена интеграция. Казалось бы - все логично, и спрос должен быть высокий, ведь мы предлагаем клиентам качественное решение в десятки раз дешевле. Но масштаб существующих решений с точки зрения количества подключенных компаний совсем не впечатляет: речь не идет о тысячах подключенных компаний, максимум о 2-3 сотнях. Отсюда вопрос:
Почему в сфере мобильных приложений нет такого спроса на подобные сервисы, по аналогии с wix или tilda в веб отрасли?
- Когда мы начали общаться с реальными клиентами, нам стало ясно, что ценность мобильного приложения как такового ясна в полной мере только крупным компаниям, которые могут себе их позволить, и нам - тем, кто их разрабатывает. Мы начинаем говорить о деталях, а клиент не понимает - зачем оно в принципе? И это вполне оправдано - небольшим компаниям не всегда нужно приложения, они попросту не имеют нужного уровня компетенций, чтобы использовать этот инструмент эффективно. В этой части мы пришли к тому, что помимо продвижения конкретно своего решения, необходимо иметь некую образовательную миссию - рассказывать, зачем бизнесу нужно приложение, как увеличить прибыль и уменьшить цену лида с помощью него.
- Даже небольшие компании, по каким-то очень невнятным причинам хотят «свое» решение. Кто-то ошибочно считает, что выгоднее заплатить один раз, и не учитывает постоянную поддержку проекта на плаву, актуализацию кодовой базы. У кого-то невероятные амбиции касаемо функциональности проекта, и в приложении нужно либо все, либо ничего. Этот пункт тоже можно отнести к необходимости образовательной функции в продажах и маркетинге подобных решений.
Не смотря на вся сложности продаж на старте пути, мы верим, что в сфере доставки еды это актуально даже для совсем небольшой дарк-китчен. А за универсальными решениями и сервисами, которые дают возможность даже небольшой компании иметь качественные digital-продукты - будущее. И таких сервисов с каждым днем становится все больше. Интересно услышать мнение коллег о проблеме в целом, и нашем решении в частности:)
Привет, мы в сети dark-kitchen ресторанов OKRA25 тоже делаем своё мобильное приложение и не используем волшебные nocode платформы.
У нас в меню много хороших блюд, которые мне очень нравятся самому. Например, пенне с лососем в розовом соусе. Мы используем специально дорогую пасту, чтобы не терялись вкусовые свойства в доставке и паста оставалась аль-денте. А самым заказываемым блюдом всё равно остаётся кесадилья с курицей и моцареллой. Стоит ли мне тоже обижаться на наших гостей, что они не едят, то что нравится мне?)
Ресторану нужно не мобильное приложение, ему нужны заказы. Агрегаторы это дают, а вы нет. Если кто-то делает собственное, то знает зачем - например, конвертить из офлайна в онлайн. Гости офлайн ресторана будут скачивать приложение для лояльности, а ресторан потом будет присылать офер на доставку (кейс кофемании, например). У вас это есть?
Объясните как с вашим сервисом ресторан будет получать заказы без сумасшедших комиссий агргегаторов и у вас будет очередь из клиентов.
Агрегаторы дают заказы, но не один из хороших ресторанов, например, в моем районе Москвы в него на заходит - потому что зарабатывают на этих заказах агрегаторы, а не ресторан.
По поводу очереди из клиентов - согласен, что из нашего текущего оффера крайне неочевидны выгоды для бизнеса, это то что мы меняем сейчас в первую очередь получив обратную связь. Безусловно мы хотим работать с болью доставок и понимаем, что само приложение для них не является самоцелью. Планируем предлагать услуги продвижения и нести образовательную миссию - объяснять зачем нужно приложение и как им пользоваться.
Да, нужно продавать решение, как инструмент для привлечения новых заказов и удержания текущих заказов.
Мне видится, что автор статьи скорее всего хотел зайти со стороны издержек. То есть, вам неизбежно нужно куда-то вовлекать пользователя. Сайт, мобильное приложение ... То есть они предлагают сократить издержки на то, что у вас должно быть.
Тем не менее, вы говорите верную идею. Интересно посмотреть, что решение не просто что-то там экономит, а именно приносит деньги. Увеличивает конверсию и пр.
Но у них на сайте об этом не говорится. Вы верно сказали про боли бизнеса, но автор этого, увы, видимо не понимает. По крайней мере, исходя из его лендинга это именно так и выглядит.
No-code мертворожденное поделие, в любом виде. В самом начале да, кажется что это панацея, но в процессе реальной эксплуатации вдруг выясняется, что у no-code очень ограниченные возможности, и все эти ноу-кодеры бегут на поклон к нормальным разработчикам.
В итоге, накликать MVP на no-code за пару вечеров - да. Выпускать в продакшн - нет.
No code пытаются впихнуть уже не один десяток лет под разными обёртками. Визуальное программирование на блок-схемах и прочие приёмы чуть ли не с 1982 года пытаются продвигать, когда вышла книга Мартина Дж. Application Development Without Programmers.
В игровых фреймворках какие-то подвижки уже есть, визуальный скриптинг в Unity как бы уже никого сильно и не удивляет до момента, когда логика не разрастётся до размера бочки с вермишелью.
Экспертное мнение, ога :)
На ноукоде не одна тысяча проектов собрана, вполне рабочих и приносящих прибыль. Взгляд на то, что ноукод панацея — полный бред. Тот кто продвигает эту идею — либо глуп, либо не разбирается.
Ноукод был и будет всегда, от него никуда не деться, ибо в основе этого движения лежит облегчение жизни юзеров. Хочешь сделать сайт-лендинг? Ручками нынче это делать бесмысленно, ибо есть та же Тильда, а если надо чего посложнее то Вебфлоу (на чём я и работаю) — на выходе чистый код словно ручками хорошего фронтэндера написанный. Надо приложуху для условного производства обуви? Бац, вот тебе и Бабл, и Адало, и многие другие инструменты.
Собирать MVP — само собой, явный путь в ноукод.
Выпускать в продашкн — конечно, чем эта тулза отличается от той? Ничем. Вопрос ограненичений. Если ваша идея реализуется в рамках того или иного ноукод стэка, то юзайте с удовольствием, ежели нет, то либо пока так, а потом ручками, либо же сразу же оными.
Те кто противятся ноукоду меня нереально забавляют, ибо они бадаются с невидимым врагом — облегчением экспириенса! :)
Скорее всего, эти люди — кодеры, программисты всякие и прочие люди. Ну оно и ясное дело, хех.
Постскриптум: я не думаю, что ноукод спасает от кода совсем, это не так — если пилить сайты на Вебфлоу, то рано или поздно захочется дополнительный функционал, которого пока нет нативно в ВФ, поэтому надо будет либо кодить самому, либо находить решение в интернете, однако даже для последнего надо будет понимать как его добавлять. Кодить — очень круто, но оно не всегда нужно, ибо есть ноукод инструменты.