Развитие ядер для запуска приложений за 2019 год. Часть 1

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

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

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

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

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

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

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

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

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

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

Возможно, кому-то из коллег будут полезны и другие фичи, вот полное описание тарифов с ценами.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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