Проектируем шеринг вещей с нуля за 250 тысяч рублей

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

Лет 5 я занимался шерингом самокатов. Этот опыт дал мне не только понимание аренды, но и довольно дорогой список того, как делать не надо. Главный пункт в нём звучит так: на старте основатель очень легко начинает строить не бизнес, а памятник самому себе.

Часть 1. Поиск поставщика.

Предупрежу сразу — названия компаний и людей намеренно не указываю: это не реклама поставщика и не попытка продать франшизу.

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

84 дня на ответ.

Российскому производителю я написал 11 марта, китайскому — на следующий день. Ответ из России пришёл 3 июня, через 84 дня. К этому моменту китайские шкафы уже были произведены, отправлены и находились на складе в Москве.

Ищем не самый дешёвый шкаф, а нормального партнёра.

В Китае много производителей, но для пилота важнее не минимальная цена, а поддержка после оплаты: документация, доступ к инженеру, тестовый софт и быстрые ответы по API. Такая поддержка оказалась полезнее дополнительной скидки на корпус. До оплаты я бы советовал проверить хотя бы следующее: 1. Что именно входит в шкаф: экран, контроллер, замки, проводка, блоки питания и ПО. 2.  Есть ли рабочая документация API, а не обещание «после оплаты всё дадим». 3. Можно ли увидеть собранное оборудование и работу ячеек по видео. Зачастую вы будете встречать торговых представителей завода, а не сам завод. 4. Готов ли поставщик дать тестовый доступ к софту и ответить на технические вопросы. 5. Кто будет помогать, если после получения начнутся проблемы, а они начнутся. Можно сразу пару базовых вопросов по API задать , чтоб понять, в каком состоянии у них тех. отдел и как быстро отвечают на вопросы, проверяем коммуникацию. Этого в целом будет достаточно , чтобы понять состояние дел на фабрике. Ну и для себя обращайте внимание на толщину стали без краски, это влияет как минимум на вес , а значит и на все виды логистики.

Ориентир для одного образца — 123 т.р. При большой партии цена ниже, но начинать с пятисот шкафов я никому не советую 🙂

Я оплатил 34 384 юаня. В заказ вошли три полностью собранных шкафа и ещё один полный комплект электроники для тестирования софта: экран, плата, замки и проводка.

как можете наблюдать, даже при коммуникации на русском, получается хорошо понять друг друга))

дата в верхней части скрина — 20 марта.

Отдельный комплект электроники — решение, которое я бы повторил ещё раз. Полноразмерный шкаф весит много и занимает половину комнаты. Для разработки он не нужен. На столе можно разложить контроллер, экран и несколько замков, подключить API и проверять весь программный сценарий: выдачу кода, открытие нужной ячейки, повторный запрос и возврат. То есть мы получили стенд для разработки, но не стали тащить четвёртый металлический корпус домой.

Что находится внутри шкафа

Габариты нашего шкафа — 1548 × 2010 × 550 мм. Внутри десять товарных ячеек разного размера и центральный отсек с экраном (10 дюймов) и управляющей электроникой.

Габариты — 1548 × 2010 × 550 мм. Десять ячеек позволяют одновременно тестировать вещи разных размеров. Весовые датчики мы не заказывали. Они покажут наличие предмета, но не его исправность, чистоту, заряд и повреждения. На пилоте после каждого возврата всё равно нужен осмотр. Автоматизацию проверки имеет смысл добавлять после появления статистики по потерям и стоимости ручного обслуживания.

Доставка: три места, 563 килограмма

Три шкафа после прибытия. Внутри партии также находился комплект электроники для стенда разработки. Доставка партии до склада в Москве стоила 2 223 доллара. На складе груз можно забрать самостоятельно или заказать отдельную перевозку до нужного города. Последняя миля оплачивается отдельно. Итого: шкаф — 123 тыс. доставка до Мск — до 60 тыс. первый месяц аренды — 5 тыс. резерв — 50 тыс +- , в результате точно до 250 тыс.

Если грубо разделить доставку между тремя шкафами, получается около 741 доллара на один корпус до московского склада. В рублях на момент заказа я закладывал примерно до 60 тыс. на шкаф. Внимание на дату. 19 мая груз уже в Мск, а кто-то еще думает над ответом)) и так вот шкафы на базе, дальше можно либо делать свой софт либо ничего не делать и запускаться.

Вариант 1: заводской софт и 0 разработки.

Самый короткий путь — попросить фабрику перевести интерфейс на русский и подключить российский платёжно-фискальный контур: эквайринг, онлайн-ККТ и отправку электронного чека. Пользователь выбирает вещь на экране, оплачивает аренду например по QR-коду, получает доступ к ячейке, а после использования возвращает товар.

Вариант 2: собственный web-слой поверх API

Мы выбрали второй путь, потому что планируем развивать продукт долго: сделали web-приложение, backend, админку и аналитику. Шкаф при этом остаётся готовым устройством, а наш слой работает через API производителя. Каждый POST-запрос подписывается SHA-512 из отсортированных параметров и секрета. Секрет хранится на backend. Заводской API мы завернули в адаптер и на настольном комплекте проверяем открытие, offline, таймаут, повтор команды, неверную подпись и потерянный callback.

Пользователь выбирает вещь и оплачивает аренду в web-приложении. Backend получает PIN выдачи и отправляет его по SMS и электронной почте; при возврате приходит отдельный PIN сдачи. Коды остаются доступны вне приложения, поэтому временные проблемы с мобильным интернетом возле точки не блокируют аренду. Успешный HTTP-ответ означает только, что команда открытия принята. API возвращает task_id, позволяет запросить состояние замка и предусматривает callback от шкафа. В состояние «вещь выдана» аренда переходит лишь после подтверждения двери. Поскольку callback в документации пока помечен как developing, на пилоте нужен резервный опрос состояния и журнала операций.

Что мы добавили в web-слой

Кроме каталога и аренды, web-слой собирает данные, без которых нельзя управлять ассортиментом и локациями:

• число оплат и успешных открытий;

•  загрузка каждой вещи и каждой ячейки;

• выручка на предмет, ячейку и локацию;

•  средняя продолжительность аренды;

• доля просроченных возвратов;

•  время, которое ячейка проводит на проверке;

•  повторные аренды;

• ошибки оплаты, выдачи кода и открытия замка;

• выручка на 1 м³

Для первой точки web-интерфейса достаточно. Нативное приложение имеет смысл делать после проверки сценария и спроса.

Возврат не означает, что вещь сразу снова доступна

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

Ассортимент зависит от локации

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

Что дальше

На момент написания шкафы получены, web-приложение и админка готовы, интеграция заканчивается. Следующий этап — полевой тест. Я намеренно не придумываю метрики до запуска. Во второй части имеет смысл показать уже реальные данные:  сколько пользователей дошло от просмотра до оплаты; какие вещи арендовали чаще;  сколько возникло ошибок открытия и возврата; сколько времени занимала ручная проверка; какая выручка получилась на одну ячейку;  где первоначальная архитектура не выдержала столкновения с реальностью. Именно здесь обычно заканчиваются красивые презентации и начинается продукт.

Вместо вывода

Первый сценарий — заказать у поставщика готовый шкаф, локализованный интерфейс и интеграцию с выбранными российскими платёжным и кассовым сервисами. Второй — оставить железо и IoT-контур заводскими, а каталог, оплату, аналитику и бизнес-логику вынести в свой web-слой через API. В обоих случаях преимущество проекта находится не в сварке корпуса, а в ассортименте, размещении, операционной модели, аналитике и удобстве пользователя. Мой личный ориентир: до выручки порядка 50 миллионов рублей полностью собственная платформа редко является первой необходимостью. После этой отметки можно начинать думать, какие части системы выгодно забирать внутрь. Если совсем коротко: меньше памятников собственному эго, больше работающих пилотов. Газуйте, тестируйте, считайте деньги и делитесь тем, что получилось. Чем меньше предприниматели прячут реальные цифры и ошибки, тем меньше каждому следующему приходится начинать с нуля.