Всем привет!

Последние несколько недель я делаю Flenta - сервис для управления велопрокатами.

Начиналось всё довольно безобидно: хотелось сделать небольшой B2B SaaS, который можно развивать без огромной команды, венчурных миллионов и необходимости собирать очередную социальную сеть.

А потом я обнаружил себя читающим документацию китайских GPS-трекеров, разбирающим GT06, думающим про собственный TCP gateway, чеки, выплаты физлицам и то, как в будущем запихнуть свой IoT-модуль внутрь велосипеда.

В общем, классическая история: «сделаю маленький сервис на выходных».

Немного обо мне

Я backend-разработчик, в основном Go, Kubernetes, инфраструктура и всё вот это прекрасное.

Но последние примерно полтора года у меня есть ещё одно довольно активно развивающееся хобби - электроника.

Начиналось всё с обычного интереса: ESP32, датчики, моторы, экраны, аккумуляторы, пайка на макетках.

Потом проекты начали становиться всё менее похожими на «помигать светодиодом».

Я собирал разные IoT-штуки, возился с моторами и драйверами, дисплеями, NFC, BLE, питанием, аккумуляторами, печатал корпуса на 3D-принтере, разбирал чужие устройства и периодически пытался понять, почему очередная китайская плата ведёт себя совсем не так, как обещает документация.

В какой-то момент понял, что хочется перейти на следующий уровень.

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

И тут довольно удачно сошлись две вещи.

С одной стороны - мой основной опыт backend-разработки и желание сделать небольшой B2B SaaS.

С другой - интерес к электронике и желание со временем дойти до собственного серийного IoT-устройства.

Так появилась Flenta.

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

У прокатов уже стоят GPS-трекеры и другие телематические устройства. За них уже платят. От них уже зависит часть операционных процессов.

То есть мне не нужно сначала объяснять рынку:

«Смотрите, было бы здорово поставить на велосипед какую-то электронную коробочку».

Электронная коробочка там уже есть. Задача скорее в другом:

«А можем ли мы сделать так, чтобы софт, устройство и сам бизнес работали как одна система?»

И это для меня значительно интереснее, чем просто написать ещё одну CRM.

Поэтому если передо мной лежит проблема, которую можно решить покупкой готового SaaS за 3000 рублей в месяц или написанием пяти микросервисов, Kubernetes-манифестов и собственного протокольного gateway - думаю, выбор очевиден.

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

Мне хотелось найти нишу, где:

• есть реальный офлайн-бизнес;
• автоматизация действительно влияет на деньги;
• рынок не состоит из трёх корпораций с миллиардными бюджетами;
• можно начать с софта, а потом постепенно уйти глубже в железо.

Так я пришёл к прокатам велосипедов.

А что вообще делает Flenta?

Если сильно упрощать, это операционная система небольшого велопроката. У владельца есть парк велосипедов. Иногда 20 штук, иногда 200. Нужно понимать:

• кто что арендовал;
• когда велосипед должен вернуться;
• где он находится;
• какому велосипеду пора на ТО;
• какие велосипеды сейчас доступны;
• сколько заработал прокат;
• что происходит с конкретным GPS-трекером;
• кому и за что нужно выплатить деньги.

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

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

Как появилась идея

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

И вот это для меня стало очень полезным моментом.

Я пришёл с мыслями про красивый интерфейс управления прокатом. А реальная точка входа в бизнес оказалась примерно такой:

«А можете наши текущие трекеры подключить к своей системе?»

После этого архитектура проекта несколько изменилась.Потому что одно дело - CRUD для велосипедов. И совсем другое - принять соединение от сотен железок неизвестного китайского происхождения.

Прототип

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

• создать парк;
• добавить велосипеды;
• работать с клиентами;
• создавать аренды;
• видеть состояние велосипедов;
• принимать телеметрию существующих трекеров;
• напоминать о завершении аренды и обслуживании;
• показывать владельцу хотя бы минимальную аналитику.

При этом самая интересная часть прототипа сейчас вообще находится не во frontend.

Это gateway для IoT-устройств.

Типичный GPS-трекер открывает TCP-соединение с сервером и начинает присылать бинарные пакеты. А дальше начинается археология. Протокол устройства может быть GT06. А может быть похож на GT06. А может производитель утверждать, что это GT06, но половина команд реализована немного иначе.

А может документации вообще не быть.

На этом месте я впервые начал значительно лучше понимать существование Traccar.

Почему я не использовал просто Traccar

Первой очевидной мыслью было: зачем вообще писать это самому?
Есть Traccar. Он уже поддерживает огромное количество устройств и протоколов. И для первого запуска использовать его вполне можно.
Но у меня есть довольно конкретная долгосрочная цель: устройство для Flenta должно быть не отдельной системой мониторинга, прикрученной сбоку, а частью продукта.

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

Поэтому текущая архитектура выглядит примерно так

Gateway отвечает за соединения с устройствами, sessions и конкретные протоколы.Внутри есть protocol manager и отдельные handlers.Протоколы не должны растекаться по бизнес-логике приложения. Если завтра вместо GT06 появится очередной SUPER-GPS-4G-V27-PRO, хотелось бы написать ещё один adapter, а не переписывать половину системы. В этом месте я придерживаюсь довольно обычной hexagonal architecture.

Не потому что «так написано в книжке», а потому что граница между странным внешним железом и внутренней моделью здесь действительно очень полезна.

Стек

Backend — Go.

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

• gateway;
• telemetry;
• основной backend;
• auth;
• дальше будут payments/notifications.

Между ними gRPC и событийное взаимодействие там, где оно имеет смысл.

Хранение - PostgreSQL.

Разворачивается всё в Kubernetes.

Здесь можно справедливо спросить:

«Ты делаешь MVP для пары прокатов. Нахрена тебе Kubernetes?»

Ответ очень простой: кластер у меня уже существует и в нём живут другие мои проекты. Он обходится примерно в 6000 ₽ в месяц, поэтому отдельной инфраструктуры под Flenta я сейчас фактически не покупаю. Если бы кластера не было - для MVP я бы Kubernetes точно не поднимал.

Frontend пока намного скучнее backend. И я использую React и NextJs

И это, пожалуй, хороший знак.

Аутентификация оказалась неожиданно интересной

Сначала кажется, что это вообще не проблема.

Потом открываешь стоимость SMS.

Отправка одной SMS получается примерно от 8,5 ₽.

А за имя отправителя некоторые операторы хотят отдельную ежемесячную плату. В моём случае получается порядка 10 080 ₽ в месяц только за sender name. Для небольшого SaaS это уже не «мелочь». Поэтому сейчас рассматриваю несколько вариантов:

• Email OTP.
• Звонок с последних четырёх цифр номера.

И довольно забавную схему авторизации через звонок на специальный номер.

Мы заранее знаем телефон пользователя. Генерируем временный номер/сессию на пять минут. Пользователь звонит. Получили входящий с правильного телефона → авторизовали.

Никаких кодов вообще.

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

Как искал первых пользователей

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

Начал писать владельцам прокатов напрямую. Без презентации на 60 слайдов и TAM/SAM/SOM. Примерно:

«Делаю систему управления прокатами, расскажите, как сейчас работаете».

И первый же нормальный разговор оказался полезнее нескольких дней самостоятельных исследований. Например, я узнал, что у конкретного проката примерно 180 велосипедов, отдельной CRM нет, а велосипеды уже оборудованы сторонними модулями, за которые платится абонентка. Я предложил им бесплатный пилот. Причём не в формате:

«выкиньте всё старое и переходите к нам».

Наоборот.

Если получится определить модели установленных устройств и найти их протокол - попробуем подключить хотя бы часть существующего парка к Flenta.

В будущем хочется дать им уже наше устройство. Они согласились попробовать продукт. Так у проекта появился потенциальный пилот примерно на 180 велосипедах ещё до того, как продукт успел стать продуктом. И это одновременно очень приятно и очень страшно.

Потому что теперь нельзя бесконечно двигать кнопочки в Figma.

Самая неожиданная проблема: железо уже существует

Когда я только смотрел на этот рынок, мне казалось:

«Ну потом сделаем GPS-модуль».

Теперь я понимаю, что «GPS-модуль» - это примерно как сказать «потом сделаем автомобиль». Там есть:

• GPS/GNSS;
• LTE;
• SIM;
• антенны;
• питание;
• режим сна;
• резервная батарея;
• входы/выходы;
• CAN/UART/RS-485 в зависимости от транспорта;
• корпус;
• влага;
• температура;
• вибрации;
• сертификация;
• производство;
• прошивка;
• OTA;
• серверный протокол.

И всё это ещё должно стоить адекватных денег.

Поэтому собственное устройство я сознательно отложил. Сначала хочу научиться работать с тем железом, которое уже установлено у клиентов. А уже потом делать своё. Мне кажется, это вообще важный вывод для hardware-related проектов:

не надо начинать со своего hardware, если ценность продукта можно проверить на чужом.

Деньги

Пока Flenta заработала ровно 0 ₽.

И мне кажется, для такого поста гораздо интереснее написать именно это, чем рисовать потенциальный миллиардный ARR. Зато уже есть расходы, которые помогают считать будущую экономику.

• Инфраструктура сейчас около 6000 ₽/месяц, но она используется не только Flenta.

• Sender name для SMS - около 10 080 ₽/месяц.

• SMS - от 8,5 ₽ за штуку.

• Налог - 6%.

Эквайринг, в зависимости от схемы, получается примерно 2–2,3% плюс сопутствующие расходы. Если через систему в будущем пойдут деньги арендаторов, появляются ещё выплаты владельцам, чеки и вопрос агентской модели. И вот здесь становится понятно, почему я не хочу делать тариф:

499 ₽ в месяц за весь прокат.

Одна только активная SMS-коммуникация способна съесть значительную часть такой подписки. Скорее всего, базовая модель будет состоять из подписки за парк плюс отдельных платных вещей, которые имеют переменную себестоимость.

Например SMS-уведомления.

А почему вообще велосипеды?

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

Сначала надо заставить нормально работать велосипеды.

Что дальше

Ближайшая цель довольно приземлённая. Дотащить MVP до состояния, в котором его можно дать пилотному прокату. Подключить хотя бы несколько реальных устройств. Посмотреть, что сломается. Потом подключить ещё. Мне намного интереснее увидеть 10 велосипедов, которые реально ездят и присылают данные, чем нарисовать dashboard для 10 000 виртуальных велосипедов. После пилота станет понятнее, какие функции действительно нужны владельцу проката, а какие я придумал себе сам. И только после этого хочется возвращаться к своему IoT-модулю.

Где мне особенно пригодилась бы помощь Клуба

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

Особенно интересно поговорить с теми, кто:

• делал продукты вокруг GPS/IoT/телематики;
• работал с GT06 и другими китайскими протоколами;
• запускал небольшие hardware-продукты в России;
• знает рынок вело-/самокато-/транспортных прокатов изнутри;
• строил платежную схему, где деньги от конечного клиента потом должны уходить владельцу площадки;
• запускал вертикальный B2B SaaS и может рассказать, где я сейчас особенно сильно заблуждаюсь.

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

Не столько ради продажи, сколько ради очередного reality check.

Потому что сейчас он для проекта значительно ценнее ещё одной написанной мной фичи.

И главный вывод на текущий момент

Я пока слишком рано в этом проекте, чтобы раздавать советы про построение успешного SaaS. Но один вывод уже сформировался.
Как разработчику очень легко начать писать решение раньше, чем ты понял проблему. Если бы я сразу реализовал первоначальное видение Flenta, сейчас у меня была бы вполне приличная CRM для велопроката. Которую никто не просил. Один разговор с владельцем реального парка изменил roadmap сильнее, чем несколько недель разработки. Поэтому сейчас мой главный KPI - не количество закрытых задач в Git.

А количество моментов, когда реальный пользователь говорит:

«Нет, у нас вообще всё работает не так».

Пока именно из них и получается самый интересный продукт.