Как мы запустили платформу для бизнеса в сфере услуг
Рассказываю о том, как мы сделали своё ядро для приложений с идеей заказа услуг, о получившейся первой версии и нагрузках.
Рассказывает Денис Гордиенко, генеральный директор Bright Mobile.
В предыдущей статье я рассказывал о том, что мы остановили продажи своего предыдущего проекта, который был некой функциональной репликой с YouDo. Причины было две - снижение спроса на классический "YouDo в своём городе" и спрос на приложения, где есть заявки и исполнители, где нужно было только 50% функционала нашего проекта и, вместе с тем, требовались серьёзные доработки под ту или иную идею клиента.
Проанализировав весь опыт, решили, что нужно запустить принципиально новый продукт, который будет не "законченной платформой", а неким ядром, которое объединяет общие требования к таким проектам и оставляет лёгкость в модернизации "под себя". В ядро выделили такой функционал, который есть в большинстве Убер-подобных проектах:
- Создание заявки с выбором категории
- Список заявок для исполнителя, отфильтрованные по направлениям его деятельности
- Возможность отправить предложение на заявку
- Список исполнителей и просмотр профиля, с возможностью связаться
- Общение во внутреннем мессенджере или прямой звонок по телефону
- Отсутствие авторизации с привязкой к устройству (есть возможность в настройках указать данные для восстановления)
- Список своих заявок, с возможностью удалить неактуальные
На лендинге расписал юзер-кейс работы для простоты восприятия.
Техническая платформа
В качестве стека технологий выбрали Ionic + Firebase. Приложение на Ionic работает существенно быстрее, чем стандартный WebView. Например, чтобы обеспечить быстрое переключение экранов в Сервис ПИ нам пришлось ломать голову над нативными переходами. Вместе с этим, сохраняется принцип экономии на доработках при развитии проекта по сравнению с чистым нативом - экраны создаются на HTML, а логика на Angular. То есть экран делается один раз сразу для iOS и Android.
Firebase тоже был выбран не случайно. Во-первых, вопрос нагрузки. База предоставляется Гуглом, как услуга в виде 100 бесплатных онлайн подключений, в среднем это 10 тыс установок приложения. А за $25, по сути цена средненького VPS-сервера, предоставляется 100 тыс онлайн подключений (~100 млн установок). Получается, что клиенты которым мы запустим приложение могут не париться по поводу "какую нагрузку выдержит приложение" от слова совсем. Вторая причина выбора Firebase исходит из первой - клиентам просто не нужен сервер. Приложения подключаются напрямую по REST API к базе данных. Казалось бы, причина не очень существенная, но за 2 последних года у нас было около 10 клиентов, которые потеряли свой проект тупо забыв продлить аренду сервера.
REST API. Отдельно хочу рассказать про интерфейс взаимодействия Firebase. Кроме приложений, само собой, можно подключить любую внешнюю систему, к примеру, сайт или CRM, чтобы обмениваться данными в обе стороны.
Принципиальные особенности
Кратко расскажу почему те или иные вещи сделаны так, а не иначе:
- Принцип Real Time. Почти каждый второй наш клиент задаёт вопрос по скорости работы приложения. Поэтому платформу было решено сделать по принципу системы реального времени.
- Работа без авторизации. Статистика показала, что многие пользователи отваливаются на этапе "поставил приложение - не стал регистрироваться". Решили этот вопрос привязав профиль к устройству, с возможностью восстановления данных, если в профиле указаны контакты.
- Биржа / список. Постоянно идут разговоры о том, чей бизнес-процесс удобнее: YouDo (клент размещает заявку, а исполнители отправляют ему отклики), либо Яндекс.Услуги (клиент выбирает мастера из списка мастеров). Решили реализовать оба этих механизма, чтобы владелец приложения сам определял какой больше подходит его проекту.
- Связь с мастером. Практика показала, что после выбора мастера клиент не ставит его исполнителем по заданию, а переводит обсуждение в офлайн. Сделали этот процесс удобным - при клике на отклик можно увидеть профиль мастера, написать ему в мессенджер или позвонить.
В планах по дальнейшим обновлениям видим реализацию конструктора форм, чтоб программист мог быстро создать много категорий заказа услуг с разными полями, подключение эквайринга и монетизации за отклик и подписку и открыт вопрос по сайту - делать ли вообще, делать в виде лендинга или создавать полнофункциональный сайт, дублирующий работу приложения. Само собой, план будет корректироваться на основе просьб купивших ядро клиентов.
Кому это нужно?
Я вижу, что наш стартап будет полезен нескольким группам клиентов. Если угодно, то наша ЦА такая:
- Основатели проектов, которые только решили протестировать проект по модели заказчик - задание - исполнитель и им нужно быстрое и дешёвое решение для теста
- Основатели проектов с продуманной логикой, сформировавшие виденье конечного продукта и им нужно решение, которое будет выдерживать до 100 млн пользователей
- Разработчики приложений и сайтов, с заказом на подобные проекты и которые хотят увеличить маржинальность сделки.
В первых двух случаях разработку проекта до победного конца будем осуществлять мы, либо программист клиента, а в третьем мы предоставляем платформу и наши коллеги разрабатывают конечный продукт под требования конечного клиента.