Денис Гордиенко, руководитель Bright Mobile, об итогах развития собственных продуктов в 2019 году и планах на 2020. Рассказываю что и почему не получилось в ушедшем году и какие сделали выводы. В этой части буду говорить про ядро для маркетплейсов услуг, ядро для досок объявлений и сервис по обработке персданных в РФ.

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

Закрытие Сервиса ПИ

Год начался с того, что мы закрыли наш первый коробочный проект «Сервис ПИ». Домен уже недоступен, но что он из себя представлял можно посмотреть здесь. Изначально это было ядро для запуска маркетплейсов услуг с сайтом и приложниями, но в один прекрасный день мы поняли, что он слишком оброс функционалом, и с этим нужно было что-то делать.

Судите сами: у него было 37 экранов, причём, экранов и приложения, и сайта. Продавался он тогда в районе двухсот тысяч рублей, но ситуация была такова, что клиенту все эти экраны просто не требовались. Получалось, что клиент хотя и покупал продукт по низкой цене (ведь разработать с нуля всё это было ещё дороже), но переплачивал, так как из приобретённого часть так и оставалась для него ненужной.

По назначению использовалось лишь 50‑70% функционала, а остальное клиент попросту просил удалить. Нередко заказчики даже сами предлагали нам урезать продукт и продать им лишь то, что они хотели за полцены, но поскольку работа над сокращением функционала сама по себе требует дополнительных временных и трудовых затрат, такое предложение не устраивало уже нас.

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

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

Именно поэтому в конечном итоге мы приняли решение этот проект закрыть, но вместе с тем сделать новое ядро «RTPlatform».

Запуск RTPlatform

Мы решили сохранить в новом ядре идею маркетплейса, но сменить парадигму внедрения. Сервис ПИ продавался, как готовое решение с сайтом и приложением, на котором уже можно было тестировать MVP маркетплейса услуг. RTPlatform стал неким ядром, которое требует доработки, но не несёт избыточного функционала. То есть получается такой скелет, который дополняется «мясом» конкретной идеи.

Технически ушли от использования Битрикса, как серверной части, да и вообще от работы с реляционными БД. Ведь в маркетплейсе важна скорость — уведомления о заданиях, уведомления о новых откликах, сообщения в чате, это всё должно приходить моментально. Стали смотреть в сторону баз данных реального времени и больше всего понравилась Firebase. Больше всего зацепила готовая серверная инфраструктура от Гугла. Из основных плюшек, которые нам понравились выделю:

  • Возможность СМС-авторизации с бесплатными 10 000 СМС в месяц
  • Собственное хранилище файлов
  • Собственный push-сервис FCM
  • 100 000 онлайн подключений даже на бесплатном тарифе, с расширением до 200 000 за $25 и кластеризацией, если этого будет мало.
  • Мониторинг производительности. Очень удобная штука, чтобы посмотреть на что расходуется серверный трафик и оптимизировать нагрузку.

Сами приложения реализовали кроссплатмформенно на Ionic.Framework. Изначально в нём было около девяти экранов – потом необходимый функционал вырос до пятнадцати. Мы учли прошлый опыт и сохранили лишь то, что нужно было всем клиентам Сервиса ПИ, отрезав 22 экрана и весь сайт, которые использовались далеко не во всех проектах. Благодаря этому смогли понизить стоимость продукта в начале года, когда он ещё был недостаточно оттестирован и доработан.

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

Итак, мы начали продажи нового ядра по стоимости в 50 тысяч рублей, потом, исправив все баги, увеличили её до 90 тысяч. Сейчас оно продаётся за 190 тыс. К изначальным 15 экранам и багфиксу добавилось несколько важных для старта фишек:

  • Делаем три произвольные доработки под клиента бесплатно. Это позволяет запустить более индивидуальное решение, даже при ограниченном бюджете на MVP
  • Переработано разделение функционала компонент и сервисов. Не вдаваясь в технические детали удалось увеличить скорость работы приложения до уровня натива.
  • Реализован паттерн отображения асинхронных данных в т.ч. отображение процесса загрузки при их отсутствии
  • Подписка на Push-уведомления перенесена на сервер для лучшего контроля подписки, теперь в мобильном приложении нужно только сохранить подписку — это удобно для программистов поддержки, которые далее развивают проекты клиентов.
  • Серверные функции переписаны на TypeScript и благодаря строгой типизации ошибок до сборки будет выявляться больше. Опять же, для программистов поддержки важно в паблик выложить проект без багов.

Глобально увеличели цену за счёт того, что теперь в стоимость входит три доработки под клиента и код проекта документирован и имеет более правильную архитектуру, чем первые версии, у программистов, которые будут вести проект далее будет меньше шансов что-то сломать.

Структура экранов

На данный момент RTPlatform имеет такие экраны в ядре:

  1. Регистрация / авторизация [бесплатные 10 000 СМС в месяц]
  2. Список своих заявок
  3. Создание новой заявки
  4. Все заявки в сервисе [фильтруются по подпискам]
  5. Подписки на категории заявок [приходят push при новой заявке в подписанной категории]
  6. Просмотр заявки и отклик на неё [как в YouDo мастера отправляют предложения на заявку]
  7. Просмотр профиля мастера [c возможностью позвонить или написать в чат]
  8. Создание своего профиля мастера
  9. Список всех мастеров сервиса [альтернативный способ, если не хочется создавать свою заявку]
  10. Переписка с пользователем [у мастера показывается ссылка на профиль]
  11. Уведомления [список всех пришедших push — новые задания, новые отклики, сообщения в переписке, движения по балансу]
  12. О Сервисе [общая информация о приложении]
  13. Пользовательское соглашение [юридическая информация о сервисе]
  14. Баланс [движения по балансу мастера и интеграция с Яндекс.Деньгами, с возможностью изменить эквайера]
  15. Меню

По сравнению с Сервисом ПИ ядро стало куда проще функционально, но подготовленное к более серьёзным нагрузкам. Вместе с этим, использование Firebase повлекло за собой требования к обеспечению серверной части в юрисдикции РФ.

Тест идеи FireDump

К моей статье про разработку один из наших конкурентов, продающих схожее ядро для маркетплейсов услуг, написал несколько комментариев о нарушении законодательства РФ:

Речь о том, что вы втираете клиентам про Firebase, про сто миллионов чего-то там — они ведутся.Но проблема в том, что вы всё тупо храните там, потому что это очень просто, примитивно и дёшево в реализации.Но почему ваши клиенты не получают от вас информацию по 12 статье 152ФЗ?

Или инфраструктура Firebase переехала куда-то под Волгоград или в Химки чтобы можно было это использовать в качестве основного и по сути единственного хранилища ПД?

Руслан Семагин

Отбросив культуру общения Руслана в сухом остатке остаётся одна претензия к Firebase / нашей реализации:

  • Если приложение использует персональные данные пользователя, то обработка и прочие действия необходимо производить на территории РФ.

Вместе с тем, допускается одновременное использование ресурсов сервиса в РФ и зарубежом. Здесь важно сделать лирическое отступление и разобраться в целесообразности траты ресурсов.

Проблема курицы и яйца

На самом деле, пока ещё не видел в РФ ни одного адекватного дата-центра, даже если оставить за скобками прочие плюшки Firebase. Разбирая в декабре всю эту ситуацию, ловил себя на двух мыслях:

  1. Составление требований по законодательству — это вопрос явно не разработчика. Если основатель собирается серьёзно зарабатывать с проекта, то потратить 10 тыс на консультацию юриста можно без проблем. В принципе, это и делали те наши клиенты, которые подписывали договора с бюджетом от 800 тыс за проект.
  2. Самый важный вопрос. Что мы собираемся делать — зарабатывать деньги или соответствовать закону?

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

По моему убеждённому мнению, нужно заниматься делом, а не бюрократией, иначе останешься с ооошкой, но без денег.

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

К слову, по нашим оценкам сделать такой дубль — это всего 50‑70 тыс к сумме проекта, но, повторюсь, на мой взгляд — это нужно делать на второй-третьей версии, а то ведь можно совсем уйти в дебри и пойти регистрироваться оператором персональных данных, соблюдать закон о мессенджерах, получая лицензию в ФСБ, а, если вдруг у вас есть новостная лента и большое количество пользователей, то и закон о СМИ нависает…

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

Вместе с тем, предполагаю, что не один Руслан боится проблем с Роскомнадзором и есть люди, которым нужны фишки Firebase, но есть страх получить претензии. Как раз для этого мы решили сделать Saas-решение c идеей хранилища персональных данных и соблюдения всех законодательных норм. Прошу написать мне на почту читателей, которых волнует этот вопрос и есть или планируется проект на firebase — мне сейчас важно собрать общую картину, чтобы грамотно сформулировать saas.

Ядро для приложений доски объявлений SalesBoard

Изначально наша идея заключалась в том, чтобы создать общую коробку, а также опциональные модули, которые будут приобретаться клиентом по желанию. Иными словами, реализовать всё, как в «Сервис ПИ», только более умным способом: создать конструктор из маленького ядра и деталей, которые он берёт лишь если оно ему нужно.

Но в итоге получилось так, что эти модули чаще всего получались слишком крохотными – настолько, что их разработку проще было бы доверить программисту под каждый проект отдельно, чем предлагать как готовый индивидуальный продукт.

Доску SalesBoard мы запускали как отдельный продукт научившись на «горизонтальном продукте», но вс-равно пришли к тому, что доска объявлений и маркетплейс услуг, где есть либо объявления о заданиях, либо каталог исполнителей, это очень близкие сущности, где просто либо есть отклики на объявления, либо их нет. Всё остальное на 90% одинаковое.

Для доски, к концу года, вышла такая структура:

  1. Регистрация / авторизация [бесплатные 10 000 СМС в месяц]
  2. Список своих объявлений
  3. Создание нового объявления
  4. Все объявления в сервисе [фильтруются по категориям]
  5. Категории объявлений [приходят push при новой заявке в подписанной категории]
  6. Просмотр объявления с возможностью позвонить или написать во внутренний чат продавцу [как в Авито]
  7. Создание своего профиля продавца
  8. Просмотр профиля продавца
  9. Переписка с продавцом [у пользователя показывается ссылка на профиль]
  10. Уведомления [список всех пришедших push — новые объявления, сообщения в переписке, движения по балансу]
  11. О Сервисе [общая информация о приложении]
  12. Пользовательское соглашение [юридическая информация о сервисе]
  13. Баланс [движения по балансу продавца и интеграция с Яндекс.Деньгами, с возможностью изменить эквайера]
  14. Меню

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

В заключение поделюсь статистикой запусков за 9 месяцев после первого релиза. Всего было заключено договоров на 27 проектов, из них 3 по той или иной причине не дошли до публикации, 5 были запущены на чистом ядре с бесплатными, либо небольшими доработками, остальные 19 — это либо кастомные проекты на основе ядра, которые уже запущены, либо те, которые в процессе разработки.

Некоторые приложения, которые уже запущены и не под NDA можно посмотреть в плейлисте:

Спасибо всем, кто продержался до конца статьи. Планирую, в ближайшем будущем написать ещё 2 части: про ядра для товарного маркетплейса и социальной сети, и про ядра, которые у нас не пошли с выводами почему так случилось.

PS Если вы мой коллега и занимаетесь разработкой сайтов или приложений, то напишите мне в ВК или Fb, за месяц бывает 5‑10 обращений, которые не профильны для моих продуктов и бывает нужно посоветовать грамотных разработчиков. Ценовой сегмент разный.

Материал опубликован пользователем.
Нажмите кнопку «Написать», чтобы поделиться мнением или рассказать о своём проекте.


Написать