Ищете слаженную команду разработки?
Готовы помочь с дизайном и разработкой приложений для бизнеса и стартапов
В 2021 году уже довольно сложно найти людей, которые переписке и заказам в онлайне предпочтут звонки и общение с персоналом. Остро проблема стоит в ночных клубах: приходится ждать официанта, разговаривать с ним, ждать заказ. Клубу обычно сложно отслеживать денежные потоки: кто заплатил, а кто нет.
А что если все это можно текстом? Так мы в Purrweb сделали сразу 5 приложений, которые сводят личное общение к минимуму.
Поменьше общения, побыстрее заказы
Локдаун стал словом года и поводом для разработки новых технологий и мобильных приложений. На старте первой волны, в апреле 2020 года, к нам в Purrweb пришел бывший профессиональный игрок в американский футбол Вернанд Моренси с идеей создания системы приложений для ночных клубов, которая сократит личное общение.
Но на фоне локдауна никто не отменял вечных проблем: невозможно дождаться официанта, а когда дождешься, понимаешь, что нужно подождать еще и другого работника, если тебе нужны танцовщица или кальян. Кроме того, думаю, вы представляете, как хаотично распространяются деньги в ночных клубах: кто-то в нетрезвом состоянии переплатит, кто-то — недоплатит, а кто-то вообще не заплатил. Любому клубу нужна понятная система учета денег.
Чтобы покрыть все эти сценарии нам предстояло разработать сразу 5(!) приложений:
- для танцовщиц;
- для кухни;
- для официантов;
- для гостей;
- админка, чтобы управлять этим всем.
…и не забывайте про систему платежей, конечно.
Таким образом, со стороны гостя это одно приложение, чтобы заказать все, что ему нужно без официанта и там же оплатить заказ. А со стороны клуба — одна большая приборная панель, которая уменьшает энтропию в заведении и помогает отслеживать денежные потоки.
Но вы когда-нибудь пробовали за полгода собирать 5 приложений параллельно, чтобы затем слить в одну инфраструктуру? Мы тоже нет, но вот как это было.
Единственная привычная вещь в проекте — стек
Для разработки использовали наш стандартный и проверенный множеством проектов фреймворк — React Native. Решили пойти по стандартному пути: дизайн → разработка с тестированием → релиз и лендинг про всю систему. К разработке с нашей стороны подключились:
- менеджер,
- четыре разработчика (1 тимлид, 1 на бэке и 2 на фронте)
- дизайнер.
Мы встречались с заказчиком на демо раз в две недели и регулярно получали от него новые идеи для приложений. На этом привычные для нас вещи в разработке закончились.
Над всеми пятью приложениями мы работали параллельно и по всем фронтам.
Работу построили так: два фронтендера и один бэкендер сделали приложение для гостя. После разработки базовой функциональности перешли к приложениям для официантов и танцовщиц, вебу для кухни и админке. На админке добавился еще один бэкендер, который писал отдельные запросы для кухни. С этого момента начали сплититься, а тимлид уже занимался только бэком.
Все системы связаны друг с другом: в каждом нельзя было двигаться дальше, пока к этому не были готовы остальные системы. Тестировать такое тоже непросто: вы не тестируете одно приложение изолированно, поскольку большинство фичей существует сразу в нескольких приложениях.
Жонглирование приложениями
Самое сложное — собрать флоу заказов воедино, потому что ролей и приложений несколько. Вот что заложили в проект:
- Отслеживает все заведения, создает пользователей (админов).
- Добавляет стафф, еду, напитки для своего заведения.
- Авторизуется: вводит имя и фамилию, загружает фотографии документа, селфи (которое подтверждает реальность гостя). Мы автоматически сверяем фото на документе с селфи через Amazon Facial Recognition. После идентификации приложение генерит QR-код для получения заказа. В QR-код зашивается вся информация по заказам и оплатам гостя. В бэклог отложили проверку возраста для продажи алкоголя.
- Если гость инициирует заказ, он генерирует QR-код через идентификацию. Если танцовщица подходит сама, гость генерит код, танцовщица его сканирует, танцует, а затем выставляет счет. Она сама решает, будет танцевать или нет, сама назначает цену.
- Получает входящие заказы.
- Выбирает заведения для работы, управляет заказами.
- Если танцовщица на смене, ее карточка отображается в приложении у гостей.
Обычно на один билд вручную уходит около 30 минут, но у нас не одно приложение, в регулярном обновлении нуждаются сразу два. Такое отнимает много времени. К тому же у нас было два разных бэка: один для стейджинга (тестирование билдов в TestFlight и Google Play Console) и один для релиза приложения. Все вместе отнимает очень много времени.
Чтобы ускорить процесс, мы подключили свой репозиторий на Gitlab к App Center и автоматизировали сборки. Это стоило нам 40 $ в месяц, но экономило 4-5 часов в неделю.
Чудесное обновление платежной системы
Но еще сложнее было с оплатой и налогами. Вот как мы договорились на старте: 4 % с каждого заказа клуб/ресторан/кафе/бар переводит суперадмину (тот, у кого есть доступ ко всем возможностям инфраструктуры). Процент един для каждого заведения.
Перед релизом заказчик переосмыслил всю систему платежей и взносов, и вот что получилось:
- % с каждого заведения свой (4-6% и выше);
- наценка на продукты, которые заказывают гости, 20 % и их клуб забирает себе;
- налоги: 20 % с суперадмина и 10 % — с владельца заведения;
- service fee (плата за услуги) (которые, кстати, нельзя брать с танцовщиц).
Эти договоренности влияли на архитектуру приложения, поэтому, когда к концу проекта заказчик-таки определился окончательно с распределением платежей, нам пришлось значительно перекроить оплату заказов и чаевые. Из-за этого изменилась структура базы данных и соответственно всех проектов, на которых выводится эта информация.
Нужно было грамотно провести всю математику: посчитать, сколько по факту будет платить посетитель заведения, сколько за каждую транзакцию будет забирать платежная система.
С этим знанием мы сходили на десяток коллов, каждый раз возвращаясь к заказчику, валидируя просчеты и внося изменения.
Мы решили интегрировать в наши приложения Stripe. Он легко коннектится с веб-сервисом, но совсем другое дело — мобильное приложение на React Native. Тогда мы откопали опенсорсную библиотеку tipsi-stripe. Но за полгода-год Stripe переписал свой API, и к моменту нашего старта стало понятно, что библиотека устарела и нам не подойдет.
Пока мы, уже немного нервничая, искали альтернативы, выяснилось, что какой-то энтузиаст выкатил обновление для библиотеки tipsi-stripe. И в нем было все, что нужно: привязка карт, payment intent’ы. Полагаем, что нам невероятно повезло. И хотя обновление помогло не выбиться из сроков, сейчас мы понимаем, что выход все равно бы нашли. Сделали бы обвзяки для нативных библиотек или через веб-элементы: создавая по факту веб-страницу c stripe-elements, которая с помощью webview заставляла пользователя думать, что он остается внутри приложения.
Двукратный рост бюджета
Мы работали над проектом 6 месяцев. Бюджет составил около $80 000 при планируемых $40 000, потому что приложение разрасталось элементами, без которых релиз был невозможен. Но даже $80 000 — это достаточно бюджетно для пяти приложений, платежной системы и админки.
Аналогов нашей системы на рынке сервисов для клубов и баров нет.
Каждому гостю отдельный официант
У Вернанда Моренси большие планы на разработанную систему: планирует упаковать инфраструктуру и начать сотрудничать со многими клубами и барами. Зарабатывать планирует с процентов с каждого чека. На старте у Вернанда было 3 заведения-партнера в разных штатах США — сейчас они уже тестируют систему. Мы адаптировали платежи под налоговую систему каждого штата и зарелизили приложение: можно скачать в App Store и Google Play.
Перед запуском мы докрутили некоторые фичи:
- доделали возможность скрыть заведение — чтобы админ мог убрать клуб, с которым больше не работает.
- убедились, что платежная система работает как надо, и деньги корректно распределяются по всем счетам.
- проработали возможность закрепить конкретного официанта за конкретным гостем — официант считывает QR-код гостя и “привязывается” к нему на вечер (первым получает заказы с кухни).
