Стоит ли делать мобильное приложение
Часто заказывают мобильные приложения, даже не проверив, что этот бизнес-процесс нужен будущим клиентам. Как результат — работал в мусорку.
А так как я занимаюсь именно заказной разработкой мобильных приложений, в портфолио остаются лишь картинки.
Есть куча способов проверить свою бизнес идею, от просто объявления и подачи телефона, например в авито, до лендингов и групповых чатов. Если у вас клиентская модель сервиса, достаточно лендинга по приемке заявки, а дальше ручками поработать 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, поэтому протестировав на чат боте свою бизнес-логику можно продолжать и в мобильном приложении все с той же базой данных.
Ну и на финал немного о коде, который получился у меня в заготовке, я всю закулисную историю вынес в отдельный модуль, а в функционале оставил только самое нужное, тем нагляднее стала логика бота, посмотрите сами:
Самое главное на мой взгляд это ряд преимуществ:
- авторизация у вас уже есть, легче будет начать пользователю совершить действие
- профиль пользователя уже есть, будет что проанализировать и запустить ретаргет
- проходить проверки при публикации не нужно
- за день можно реализовать всю логику
- на следующий день начать тестировать стартап
Исходники описанного сценария в статье прилагаю.
Тестируйте, запускайте, успехов Вам!
Пойду посмотрю на сварку, чтоб глаза не так болели после просмотра кода.
Ладно на хабре, но стартаперы то должны знать что говнокод - это последняя проблема (если вообще проблема 🙄).
Согласен, но автор себя позиционирует не как стартапер, а как контрактер.
такого уровня код долны учить писать в школах :(
Все эти тарифы за потребление ресурсов могут влететь в копеечку. Будет у вас ошибка в коде или курьеры начнут раз в секунду обновлять данные и получите в конце месяца счет на $$$$. Проще сначала свой сервер за фиксированные $5 в месяц поднять на VPS
В том и дело, что не проще, особенно если ты лишь мобильный разработчик. Ну а если дойдет до того, что приложение будет расти и пользоваться спросом, то как минимум нужна дополнительная пара рук, чтобы пилить бэкенд, заниматься бд и админить этот самый сервак. Даже если найти человека который будет заниматься всем этим за 1500$ в месяц, использовать готовый baas по типу firebase, думаю, выйдет если не дешевле, то не сильно дороже. Firebase не очень выгоден только когда речь о реально больших количествах данных, хотя есть много сервисов с миллионной аудиторией, которые будучи стартапами запускались на firebase, но так и не слезли с него, потому что выгода от своих серваков не столь значительна.
MySQL поставьте бесплатный и забудьте на время про администрирование базы данных.
Вам его всё равно придётся пилить. На модели старт-апа нужно уметь всё, а дальше, если выстрелит, то делегировать и расти
Нельзя все уметь, а уж тем более успевать. Если бы так просто было в одиночку пилить бэк, заниматься базой, админить, да еще и клиент делать мобильный, то всем этим не занимались бы отдельные люди. Да, на старте можно и самому все сделать, лишь бы работало, но более менее нормальный рабочий продакшн одна пара рук не потянет этого всего, даже если будет уметь. Вот в таких случаях и выручает firebase - не нужно париться о том, что не важно на первых порах. В конце концов ничто не мешает делать проект и расти на том же firebase, а как только проект окрепнет и будет понятно что он не мертворожденный, то в случае необходимости можно съезжать на свое железо. Но опять же, в очень редких случаях проект будет настолько большим, что будет выгода от использования своего железа с бэком и найма разработчиков перед firebase, который заменяет на первых порах минимум полторы а то и две пары рук, а если учесть и возможности легкого масштабирования, которые могут пригодиться в будущем, то заменяет еще две дополнительные и в том числе сильного инженера, которые в итоге ежемесячно будут обходиться в 10к долларов только по зарплатам, не говоря о прочих расходах.
Виртуалка на том же компьютере, что и разработка с БД... администрирования там около нуля. Бесплатно.
Ваш подход тоже не панацея. Можно опросить миллион человек, провести десятки исследований рынка и т.д. и т.п. сделать приложение и один хрен никто пользоваться не будет))
Есть книга "Спроси маму" - про то, как проводить customer development интервью.
Можно как угодно прототипировать, замерять интерес, хоть экраны нарисованные показывать и собирать заявки на "попробовать приложение",
Firebase, авторизация - это все сильно позже.
Комментарий недоступен
Хз что они там допилили. С озоном сравните, как надо делать - все красиво и удобно.
До некоторых вещей веб не дотянуть
Таких вещей 0,1%. Остальное - типовуха. Но все прыгают по граблям, в итоге сторы забиты мертворожденными приложениями.
А вот ситилинку приложение бы крайне не помешало
Мобильное приложение нужно строго в одном случае - когда им удобнее пользоваться чем браузером.
Например, данному ресурсу нужно мобильное приложение? На мой взгляд абсолютно ненужно. Всё можно делать в браузере.
Тогда вообще никакие приложения не нужны, кроме браузера? Ведь на html5 все что угодно можно сделать, что будет работать в браузере, но будет жрать трафик и при медленном интернете загружаться в 10 раз медленнее, чем мобильное приложение.
VC приложение как раз нужно, т.к. иконка на рабочем столе - это халявная реклама и постоянное напоминание + пуши можно слать. А от посещаемости напрямую зависит доход СМИ.
Иконку любого сайта можно добавить на главный экран (пункт в браузере "Добавить на главный экран"). Пуши веб сайты тоже могут присылать в смартфон.
На iOS сайты не могут пуши присылать (и очень хорошо). Много вы иконок сайтов на рабочий стол добавили?)
Вы абсолютно правильно поняли посыл моего комментария. В большинстве случаев мобильное приложение не нужно.
Я бы сказал наоборот. Сайт не нужен. Достаточно мобильного приложения.
Спасибо. А десктопным пользователям что делать? Бибу полировать? Поколение смартфонных зомби, блин...
Мы же не с точки зрения пользователей, а с точки зрения стартапа.
Вам не нужны все пользователи. Вначале вам нужны те, которых получить наиболее дёшево, и с которых можно снять больше денег.
У Uber'а и Яндекс.Такси нет сайта (на самом деле есть, но он совсем не про то) — и никто не страдает.
У Facebook сайт есть, но если бы они были стартапом, сейчас они могли бы его не делать – 92% прибыли у них от приложения.
Да, потом, когда появятся ресурсы, можно и сайт запилить.
Если вы о Яндекс-такси, то да. Если об vc, то нет.
Впрочем, главное - монетаризация. Поддерживать сайт значительно дешевле приложения, но и рекламы на сайте избегать легче.
Главное преимущество приложения — стоимость удержания пользователей.
Привлечь пользователя на сайт первый раз стоит примерно столько же, сколько заставить его установить приложение.
Но зато второй раз и дальше перевес в сторону приложения – снести установленное приложение морально тяжелее, чем просто не зайти ещё раз на сайт.
Так и есть. Но мы же говорили о пользователях, об их потребностях.
Ясно. Нет, я говорил с точки зрения бизнеса, как и автор статьи.
Ещё и на Яве свою годноту написали, автор ну зачем так некрофилить
Это же TypeScript, а не Java.
И с каких пор её использование считается некрофилией?