{"id":14277,"url":"\/distributions\/14277\/click?bit=1&hash=17ce698c744183890278e5e72fb5473eaa8dd0a28fac1d357bd91d8537b18c22","title":"\u041e\u0446\u0438\u0444\u0440\u043e\u0432\u0430\u0442\u044c \u043b\u0438\u0442\u0440\u044b \u0431\u0435\u043d\u0437\u0438\u043d\u0430 \u0438\u043b\u0438 \u0437\u043e\u043b\u043e\u0442\u044b\u0435 \u0443\u043a\u0440\u0430\u0448\u0435\u043d\u0438\u044f","buttonText":"\u041a\u0430\u043a?","imageUuid":"771ad34a-9f50-5b0b-bc84-204d36a20025"}

No-code подход в мобильной разработке: будущее или мелкая ниша?

Меня зовут Алексей Жилин, я основатель агентства мобильной разработки SMD Agency, а также сооснователь стартапа Wiby, размышления о котором и натолкнули меня на написание этой статьи. Wiby - это сервис, в котором рестораны и доставки еды могут получить нативное мобильное приложение с бэк-офисом и интеграциями с основными CRM этой отрасли для своего ресторана или сервиса доставки еды. Вместо многомиллионного бюджета на разработку и дальнейшую поддержку своего приложения, наш сервис предлагает подписку от 4900 рублей в месяц. Мы совсем недавно начали свою деятельность и целью этой заметки вижу рассказать свои наблюдения и получить обратную связь от заинтересованной аудитории.

Существующие решения на рынке

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

Napsy - более универсальная модель, для ecommerce в целом.

Loyaltyplant - больше упор на систему лояльности, но много интересных клиентов в нашей нише.

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

Общий сценарий работы с нашим и аналогичными сервисами выглядит следующим образом: клиент регистрирует аккаунт, вносит контент своего приложения (товары, акции, статичная информация), при необходимости запрашивает интеграции с внутренними системами своей компании, оплачивает выбранный тариф и приложение публикуется в Play Google и AppStore. Все обновления и фиксы выпускаются автоматически для всех подключенных к сервису компаний. Заказы поступают либо в личный кабинет сервиса, либо в CRM с которой проведена интеграция. Казалось бы - все логично, и спрос должен быть высокий, ведь мы предлагаем клиентам качественное решение в десятки раз дешевле. Но масштаб существующих решений с точки зрения количества подключенных компаний совсем не впечатляет: речь не идет о тысячах подключенных компаний, максимум о 2-3 сотнях. Отсюда вопрос:

Почему в сфере мобильных приложений нет такого спроса на подобные сервисы, по аналогии с wix или tilda в веб отрасли?

  • Когда мы начали общаться с реальными клиентами, нам стало ясно, что ценность мобильного приложения как такового ясна в полной мере только крупным компаниям, которые могут себе их позволить, и нам - тем, кто их разрабатывает. Мы начинаем говорить о деталях, а клиент не понимает - зачем оно в принципе? И это вполне оправдано - небольшим компаниям не всегда нужно приложения, они попросту не имеют нужного уровня компетенций, чтобы использовать этот инструмент эффективно. В этой части мы пришли к тому, что помимо продвижения конкретно своего решения, необходимо иметь некую образовательную миссию - рассказывать, зачем бизнесу нужно приложение, как увеличить прибыль и уменьшить цену лида с помощью него.
  • Даже небольшие компании, по каким-то очень невнятным причинам хотят «свое» решение. Кто-то ошибочно считает, что выгоднее заплатить один раз, и не учитывает постоянную поддержку проекта на плаву, актуализацию кодовой базы. У кого-то невероятные амбиции касаемо функциональности проекта, и в приложении нужно либо все, либо ничего. Этот пункт тоже можно отнести к необходимости образовательной функции в продажах и маркетинге подобных решений.

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

0
80 комментариев
Написать комментарий...
Sam Beckett

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

Ответить
Развернуть ветку
Георгий Алавердян

Экспертное мнение, ога :)

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

Ноукод был и будет всегда, от него никуда не деться, ибо в основе этого движения лежит облегчение жизни юзеров. Хочешь сделать сайт-лендинг? Ручками нынче это делать бесмысленно, ибо есть та же Тильда, а если надо чего посложнее то Вебфлоу (на чём я и работаю) — на выходе чистый код словно ручками хорошего фронтэндера написанный. Надо приложуху для условного производства обуви? Бац, вот тебе и Бабл, и Адало, и многие другие инструменты.

Собирать MVP — само собой, явный путь в ноукод.

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

Те кто противятся ноукоду меня нереально забавляют, ибо они бадаются с невидимым врагом — облегчением экспириенса! :)
Скорее всего, эти люди — кодеры, программисты всякие и прочие люди. Ну оно и ясное дело, хех.

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

Ответить
Развернуть ветку
Valentin Budaev
на выходе чистый код словно ручками хорошего фронтэндера написанный

Это уже не ноукод а обычная кодогенерация.

Ответить
Развернуть ветку
Sam Beckett

Да он там все в одну кучу смешал, человек явно не разбирается в вопросе

Ответить
Развернуть ветку
Георгий Алавердян

И что же я неправильного сказал? 🥴

Ответить
Развернуть ветку
77 комментариев
Раскрывать всегда