Стоит ли делать мобильное приложение

Часто заказывают мобильные приложения, даже не проверив, что этот бизнес-процесс нужен будущим клиентам. Как результат — работал в мусорку.

А так как я занимаюсь именно заказной разработкой мобильных приложений, в портфолио остаются лишь картинки.

Есть куча способов проверить свою бизнес идею, от просто объявления и подачи телефона, например в авито, до лендингов и групповых чатов. Если у вас клиентская модель сервиса, достаточно лендинга по приемке заявки, а дальше ручками поработать 10-20 заявок. Если у вас раздача группе лиц, например курьерских заданий, групповой чат с публикацией туда заданий.

И вот вы проверили на 10-20 заявках, получили прибыль и бежите сломя голову тратить 300 - 500 тысяч рублей, чтобы проверенную модель реализовать уже в мобильном приложении, ведь 2-3 продажи, это доказательство, все 100% гарантия же.

Я бы не делал на 2-3 продажах какие-то выводы, это крайне мало, вдруг их всего возможно только 5 в месяц.

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

Разберем на примере

Разберем на часто встречаемой задаче: раздаче заявок курьерам. Тут есть 2-е подзадачи: проводить анкетирование и прием на работу и рассылка заданий прошедшим прием на работу.

Итак с рекламы пользователь переходит в сообщения сообществу по работе курьером и рассказывает что за работа, какие условия, как все будет происходить, что возить и прочее. Бот предлагает написать «Да», если пользователя все устраивает и заполнить небольшую анкету. Отлично у нас есть новая заявка приема на работу, уведомим администратора, так же сообщением из группы. Администратор просматривает профиль и анкету нового сотрудника и пропускает или утверждает его командой «утвердить и id пользователя». После этого бот уведомит новоиспеченного курьера что он принят на работу и скоро появятся новые заявки.

Администратор постит новые задания командой боту «задание и далее его текст» и все прошедшие утверждение получают его. Дальше само собой можно и нужно додумывать логику приемки в работу этого задания…

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

В роли серверной части я использую Firebase (облачный PaaS сервис от Google, который берет деньги по факту потребления услуги).

Мы будем использовать Cloud Functions для ответа серверу ВК, что же ответить пользователя и Realtime Database для хранения данных.

Считаем затраты

За Realtime Database с нас берут за скачиваемый трафик за каждый гигабайт 1$ и 5$ за хранение каждых 5Гб в базе данных. За Cloud Functions 0,4$ за 1 миллион вызовов функции.

Ну и давайте прикинем сколько 1 000 пользователей нам даст в затратах. Допустим анкету на 1000 символов он оставит и будет 300 (10 в день) команд в месяц писать. Администратор будет раздавать 100 заданий в день (3000 команд в месяц).

Итого на 1000 пользователей:

  • 1 Мб в хранилище, а у нас 1$ за 1 Гб
  • трафик вообще будет смешным, т.к. это максимум статусы текущего состояния пользователя, учитывать не стоит
  • 303 000 вызовов функции, при этом оплата 0,4$ за миллион

Следовательно заплатили бы вы меньше 1$, но Firebase предоставляет еще и бесплатный лимит на месяц, за который платить не нужно:

  • Cloud Functions 2 млн. вызовов в месяц бесплатно
  • Realtime Database 1 Гб хранилища и 10 Гб трафика бесплатно

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

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

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

// событие входящего сообщения // message - ключ-значение входящего сообщения // session - ключ-значение хранилища пользователя // по результату необходимо вернуть объект // actionMessage - ответное сообщение пользователю // newSession - новые ключ-значения хранилища пользователя // userAction - событие для другого пользователя // user_id - id пользователя события // userAction - сообщение пользователю события // newSession - ключ-значение хранилища пользователя события // job - сообщение активным пользователям onAction(message: { [key: string]: any }, session: { [key: string]: any }): Promise<Core.ActionPromise> { const messageText = message.text; const messageTextUpperCase = message.text.toUpperCase(); const user_id = message.from_id; const isAdmin = (user_id === ChatBotComponent.adminID); const commands = messageText.toUpperCase().split(' '); const command = commands[0].toUpperCase(); const param = commands[1] && commands[1].toUpperCase(); return new Promise((resolve, reject) => { if (isAdmin && command === 'УТВЕРДИТЬ') { const actionMessage = `Сотрудник утвержден.`; const userAction: Core.UserAction = { user_id: param, actionMessage: `Вы приняты на работу, ожидайте новых заданий.`, newSession: { state: 4, active: true } }; resolve({ actionMessage, userAction }); } else if (isAdmin && command === 'ЗАДАНИЕ') { const actionMessage = `Задание отправлено.`; const job = param; resolve({ actionMessage, job }); } else if (!session.state) { // Стартовое сообщение от бота if (messageTextUpperCase === 'ДА') { // После команды Да ждем анкету сотрудника const actionMessage = `✏ Опишите ваш опыт работы курьером.`; const newSession = { state: 2 }; resolve({ actionMessage, newSession }); } else { // Приветствие нового сотрудника const actionMessage = `Добрый день.\nМы набираем исполнителей на работу курьером. Если вы хотите работать у нас, напишите "да" и мы предложим вам заполнить анкету.`; resolve({ actionMessage }); } } else if (session.state === 2) { // Принимаем анкету и уведомляем админа const actionMessage = `Ваша анкета принята, ожидайте результата.`; const newSession = { anketa: messageText, state: 3 }; const userAction: Core.UserAction = { user_id: ChatBotComponent.adminID, actionMessage: `✉ Новая анкета: ${messageText}\nДля приема на работу отправьте утвердить ${user_id}` }; resolve({ actionMessage, newSession, userAction }); } else if (session.state === 3) { // Анкета принята, ждите const actionMessage = `Ваша анкета уже была принята, ожидайте результата.`; resolve({ actionMessage }); } else if (session.state === 4) { // Ожидание новый заданий const actionMessage = `⏳ Новых заданий пока для вас нет.`; resolve({ actionMessage }); } }); }

Самое главное на мой взгляд это ряд преимуществ:

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

Исходники описанного сценария в статье прилагаю.

Тестируйте, запускайте, успехов Вам!

0
31 комментарий
Написать комментарий...
Dmitry Yankovoy

Пойду посмотрю на сварку, чтоб глаза не так болели после просмотра кода.

Ответить
Развернуть ветку
Zaza B.

Ладно на хабре, но стартаперы то должны знать что говнокод - это последняя проблема (если вообще проблема 🙄).

Ответить
Развернуть ветку
Dmitry Yankovoy

Согласен, но автор себя позиционирует не как стартапер, а как контрактер.

Ответить
Развернуть ветку
Bulat Ziganshin

такого уровня код долны учить писать в школах :(

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

Все эти тарифы за потребление ресурсов могут влететь в копеечку. Будет у вас ошибка в коде или курьеры начнут раз в секунду обновлять данные и получите в конце месяца счет на $$$$. Проще сначала свой сервер за фиксированные $5 в месяц поднять на VPS

Ответить
Развернуть ветку
Bi Zzi
Проще сначала свой сервер за фиксированные $5

В том и дело, что не проще, особенно если ты лишь мобильный разработчик. Ну а если дойдет до того, что приложение будет расти и пользоваться спросом, то как минимум нужна дополнительная пара рук, чтобы пилить бэкенд, заниматься бд и админить этот самый сервак. Даже если найти человека который будет заниматься всем этим за 1500$ в месяц, использовать готовый baas по типу firebase, думаю, выйдет если не дешевле, то не сильно дороже. Firebase не очень выгоден только когда речь о реально больших количествах данных, хотя есть много сервисов с миллионной аудиторией, которые будучи стартапами запускались на firebase, но так и не слезли с него, потому что выгода от своих серваков не столь значительна.

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

MySQL поставьте бесплатный и забудьте на время про администрирование базы данных.

Ответить
Развернуть ветку
Sergei Timofeyev

Вам его всё равно придётся пилить. На модели старт-апа нужно уметь всё, а дальше, если выстрелит, то делегировать и расти

Ответить
Развернуть ветку
Bi Zzi
На модели старт-апа нужно уметь всё

Нельзя все уметь, а уж тем более успевать. Если бы так просто было в одиночку пилить бэк, заниматься базой, админить, да еще и клиент делать мобильный, то всем этим не занимались бы отдельные люди. Да, на старте можно и самому все сделать, лишь бы работало, но более менее нормальный рабочий продакшн одна пара рук не потянет этого всего, даже если будет уметь. Вот в таких случаях и выручает firebase - не нужно париться о том, что не важно на первых порах. В конце концов ничто не мешает делать проект и расти на том же firebase, а как только проект окрепнет и будет понятно что он не мертворожденный, то в случае необходимости можно съезжать на свое железо. Но опять же, в очень редких случаях проект будет настолько большим, что будет выгода от использования своего железа с бэком и найма разработчиков перед firebase, который заменяет на первых порах минимум полторы а то и две пары рук, а если учесть и возможности легкого масштабирования, которые могут пригодиться в будущем, то заменяет еще две дополнительные и в том числе сильного инженера, которые в итоге ежемесячно будут обходиться в 10к долларов только по зарплатам, не говоря о прочих расходах.

Ответить
Развернуть ветку
Sergei Timofeyev
Вот в таких случаях и выручает firebase - не нужно париться о том, что не важно на первых порах.

Виртуалка на том же компьютере, что и разработка с БД... администрирования там около нуля. Бесплатно.

Ответить
Развернуть ветку
тима махотлов

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

Ответить
Развернуть ветку
Георгий Хромченко

Есть книга "Спроси маму" - про то, как проводить customer development интервью.  

Можно как угодно прототипировать, замерять интерес, хоть экраны нарисованные показывать и собирать заявки на "попробовать приложение",

Firebase, авторизация - это все сильно позже.

Ответить
Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
Император Всероссийский

Хз что они там допилили. С озоном сравните, как надо делать - все красиво и удобно.

Ответить
Развернуть ветку
Wonabeez Doratie

До некоторых вещей веб не дотянуть

Ответить
Развернуть ветку
Alexey Praskovin

Таких вещей 0,1%. Остальное - типовуха. Но все прыгают по граблям, в итоге сторы забиты мертворожденными приложениями.

Ответить
Развернуть ветку
Виктор Иващенков

А вот ситилинку приложение бы крайне не помешало

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

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

Ответить
Развернуть ветку
Император Всероссийский

Тогда вообще никакие приложения не нужны, кроме браузера? Ведь на html5 все что угодно можно сделать, что будет работать в браузере, но будет жрать трафик и при медленном интернете загружаться в 10 раз медленнее, чем мобильное приложение.

VC приложение как раз нужно, т.к. иконка на рабочем столе - это халявная реклама и постоянное напоминание + пуши можно слать. А от посещаемости напрямую зависит доход СМИ.

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

Иконку любого сайта можно добавить на главный экран (пункт в браузере "Добавить на главный экран"). Пуши веб сайты тоже могут присылать в смартфон.

Ответить
Развернуть ветку
Император Всероссийский

На iOS сайты не могут пуши присылать (и очень хорошо). Много вы иконок сайтов на рабочий стол добавили?)

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

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

Ответить
Развернуть ветку
Denis Bystruev

Я бы сказал наоборот.  Сайт не нужен.  Достаточно мобильного приложения.

Ответить
Развернуть ветку
Alexey Praskovin

Спасибо. А десктопным пользователям что делать? Бибу полировать? Поколение смартфонных зомби, блин...

Ответить
Развернуть ветку
Denis Bystruev

Мы же не с точки зрения пользователей, а с точки зрения стартапа.

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

У Uber'а и Яндекс.Такси нет сайта (на самом деле есть, но он совсем не про то) — и никто не страдает.

У Facebook сайт есть, но если бы они были стартапом, сейчас они могли бы его не делать – 92% прибыли у них от приложения.

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

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

Если вы о Яндекс-такси, то да. Если об vc, то нет. 

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

Ответить
Развернуть ветку
Denis Bystruev

Главное преимущество приложения — стоимость удержания пользователей.

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

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

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

Так и есть. Но мы же говорили о пользователях, об их потребностях.

Ответить
Развернуть ветку
Denis Bystruev

Ясно.  Нет, я говорил с точки зрения бизнеса, как и автор статьи.

Ответить
Развернуть ветку
Wonabeez Doratie

Ещё и на Яве свою годноту написали, автор ну зачем так некрофилить

Ответить
Развернуть ветку
Artyom Zakharov

Это же TypeScript, а не Java.

И с каких пор её использование считается некрофилией?

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