Как мы запустили платформу для бизнеса в сфере услуг

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

Рассказывает Денис Гордиенко, генеральный директор 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 млн пользователей
  • Разработчики приложений и сайтов, с заказом на подобные проекты и которые хотят увеличить маржинальность сделки.

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

Вы тоже можете рассказать о своём проекте, как автор этого материала. Соберите побольше информации — и публикуйте материал в подсайте «Трибуна».
0
7 комментариев
Написать комментарий...
ugnich

Когда заказов/исполнителей мало и ты только тестируешь модель - лучше пользоваться чем-то супер-гибким, пусть и неудобным. Например, Excel.
Когда целишься на "до 100млн пользователей" - нужна своя платформа.
А разработчики приложений и сайтов будут сидеть и писать код для заказчиков, вы им не нужны.

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

Слежу с интересом. Держите в курсе. :)

Ответить
Развернуть ветку
Денис Гордиенко
Автор

Спасибо за веру нас и перспективы :)

Ответить
Развернуть ветку
Пётр Загребельный

Внимательно ознакомился со статьёй, так и не понял в чем суть проекта🧐 ну пишем мы разные приложения? За счёт чего увеличить маржинальность? Поясните пожалуйста :) я реально вашу статью прочитал

Ответить
Развернуть ветку
Денис Гордиенко
Автор

Речь о том, что если к Вам заходит проект на разработку в формате заказчик - задание - исполнитель, то выгоднее не всю логику с нуля писать, а использовать наше ядро. Т.е. клиенту выставляете чек за разрботку с нуля, а сами экономите ресурсы на разработке, достраивая проект так сказать из заготовки. Наверное, самый простой пример - это использование CMS в разработке сайтов.

Ответить
Развернуть ветку
Пётр Загребельный

А, да нет обычно такой проблемы. Ну и для того чтобы реализовывать проекты у вас должна быть мощная серверная система с возможностью дописывать бизнес логику + api для фронтенда. Например у нас заказы по автоматизации бизнеса, например склад или личный кабинет, там n-ное кол-во модулей. Откуда у вас в системе будут эти модули? Например склад? Или документооборот? Сколько лет вы на рынке что у вас ядро которое позволит сэкономить время и деньги?

Даже SAP и 1C не смотря всю их пафосность не могут предложить ядро с гибкой архитектурой, ну или хотя бы логичной архитектурой чтобы можно было писать модули и быстро дорабатывать.

Ответить
Развернуть ветку
Денис Гордиенко
Автор

У нас вместо сервера используется Firebase + REST API для внешних подключений. Я верю что за real time database будущее. Предлагаемые Гуглом 100к онлайн подключений более чем достаточно для 99,99% проектов.

Склад, ЛК, и прочие доп.модули пишутся как раз Вами, привязываясь к нашей архитектуре. Конкретно мы для таких задач используем уже готовые инфраструктуры типа Битрикс24 и аналоги. Выбирается под конкретную задачу.

Не совсем понял вопрос про сколько лет на рынке. Лично я руковожу компаниями в ИТ с 2010г. Ядру недели две от роду.

SAP и 1C - это внутрикорпоративные ERP-системы. Причём тут мобильные приложения? И да, приложение от 1С говёненькое, т.к. это не их профиль. У нас бы была говёная программа для бухгалтерии.

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

Вы правил но думаете про ЦА, но поатить75000 чтобы проверить идею , ну такое. К тому же вы акцент делаете как я понял на приложение, а в этой сфере среди нишевых проектов востребован веб. Напишите мне в фейсбук, хочу обсудить судьбу платформы

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