Назад

Как мы за полгода разработали 4 приложения и одну админку для ночного клуба

Время чтения: 5 минут

разработка приложения для ресторана
Содержание

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

    А что если все это можно текстом? Так мы в Purrweb сделали сразу 5 приложений, которые сводят личное общение к минимуму.

    Поменьше общения, побыстрее заказы

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

    Но на фоне локдауна никто не отменял вечных проблем: невозможно дождаться официанта, а когда дождешься, понимаешь, что нужно подождать еще и другого работника, если тебе нужны танцовщица или кальян. Кроме того, думаю, вы представляете, как хаотично распространяются деньги в ночных клубах: кто-то в нетрезвом состоянии переплатит, кто-то — недоплатит, а кто-то вообще не заплатил. Любому клубу нужна понятная система учета денег.

    Чтобы покрыть все эти сценарии нам предстояло разработать сразу 5(!) приложений:

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

    …и не забывайте про систему платежей, конечно.

    Таким образом, со стороны гостя это одно приложение, чтобы заказать все, что ему нужно без официанта и там же оплатить заказ. А со стороны клуба — одна большая приборная панель, которая уменьшает энтропию в заведении и помогает отслеживать денежные потоки.

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

    Единственная привычная вещь в проекте — стек

    Для разработки использовали наш стандартный и проверенный множеством проектов фреймворк — React Native. Решили пойти по стандартному пути: дизайн → разработка с тестированием → релиз и лендинг про всю систему. К разработке с нашей стороны подключились:

    • менеджер, 
    • четыре разработчика (1 тимлид, 1 на бэке и 2 на фронте)
    • дизайнер. 

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

    Над всеми пятью приложениями мы работали параллельно и по всем фронтам.

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

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

    Жонглирование приложениями

    Самое сложное — собрать флоу заказов воедино, потому что ролей и приложений несколько. Вот что заложили в проект:

    разработка приложения для ночного клуба

    1. Отслеживает все заведения, создает пользователей (админов).
    2. Добавляет стафф, еду, напитки для своего заведения.
    3. Авторизуется: вводит имя и фамилию, загружает фотографии документа, селфи (которое подтверждает реальность гостя). Мы автоматически сверяем фото на документе с селфи через Amazon Facial Recognition. После идентификации приложение генерит QR-код для получения заказа. В QR-код зашивается вся информация по заказам и оплатам гостя. В бэклог отложили проверку возраста для продажи алкоголя.
    4. Если гость инициирует заказ, он генерирует QR-код через идентификацию. Если танцовщица подходит сама, гость генерит код, танцовщица его сканирует, танцует, а затем выставляет счет. Она сама решает, будет танцевать или нет, сама назначает цену.
    5. Получает входящие заказы.
    6. Выбирает заведения для работы, управляет заказами.
    7. Если танцовщица на смене, ее карточка отображается в приложении у гостей.

    Обычно на один билд вручную уходит около 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 — это достаточно бюджетно для пяти приложений, платежной системы и админки.

    Аналогов нашей системы на рынке сервисов для клубов и баров нет.

    Каждому гостю отдельный официант

    генератор qr кодов

    У Вернанда Моренси большие планы на разработанную систему: планирует упаковать инфраструктуру и начать сотрудничать со многими клубами и барами. Зарабатывать планирует с процентов с каждого чека. На старте у Вернанда было 3 заведения-партнера в разных штатах США — сейчас они уже тестируют систему. Мы адаптировали платежи под налоговую систему каждого штата и зарелизили приложение: можно скачать в App Store и Google Play.

    Перед запуском мы докрутили некоторые фичи:

    • доделали возможность скрыть заведение — чтобы админ мог убрать клуб, с которым больше не работает.
    • убедились, что платежная система работает как надо, и деньги корректно распределяются по всем счетам.
    • проработали возможность закрепить конкретного официанта за конкретным гостем — официант считывает QR-код гостя и “привязывается” к нему на вечер (первым получает заказы с кухни).
    Менеджмент
    • Мария Волкова
    • Дмитрий Ларин
    Дизайн
    • Сергей Мартын
    Разработка
    • Влад Дюбов
    • Александр Пуртов
    • Григорий Шарапов
    Тестирование
    • Игорь Андреев
    • Марина Болдырева
    Контент
    • Дарья Лобачева
    • Анастасия Хмелевская