Нам везет на крутые проекты для рынка Ближнего Востока. Например, мы делали финтех-приложение KEM для Кувейта — оно привлекло $1 млн инвестиций на первом этапе и более 100k пользователей. Похоже, успех ждет и наш новый проект We’re all winners — приложение для покупки скидочных купонов, ориентированное на рынок Египта. Мы так думаем не потому, что отвечали за его дизайн и разработку 🙂 Цифры говорят сами за себя.
Работу с We’re all winners мы начали в прошлом году. Жесткий дедлайн, переделки первоначального дизайна, работа с чужим фронтендом и написание бэкенда на новой для нас технологии…словом, чек-лист идеального проекта Purrweb 😄 Но результат того стоил. В этом кейсе расскажем об одном из самых классных наших проектов за последнее время.
Приложение, где покупка скидочного купона дает шанс на выигрыш приза
Весной 2023 года к нам обратились Хешам, инженер из Нью-Йорка, и Мухамед, владелец бизнеса, который жил в Каире. Вместе со своей командой они делали приложение для продажи скидочных купонов, ориентированное на рынок Египта. В мире существует сотни аналогичных онлайн-сервисов, но наши заказчики придумали, как выделиться на их фоне.
Киллер-фича приложения — это розыгрыши среди покупателей купонов. В большинстве подобных сервисов все ограничивается только скидками, а здесь у людей есть возможность выиграть призы. Отсюда и название: We’re all winners, или WAW.
Кстати, как вообще работает эта тема с купонами? Если вы хоть раз гуглили «купоны на скидки» в своем городе, то примерно представляете 🙂 Если нет, объясним на примере WAW.
Покупка купона в приложении WAW
WAW заключает контракты с вендорами — магазинами, ресторанами, клубами и так далее. Затем в приложении продаются предоплаченные купоны, которые позволяют юзерам приобретать товары или услуги от вендоров с хорошими скидками.
Все остаются в выигрыше👌 Юзеры экономят, бизнесы получают дополнительный канал рекламы или возможность продать излишки товаров, а наши заказчики зарабатывают свой процент.
Кроме того, вендоры спонсируют розыгрыши в We’re all winners, и это помогает привлекать новых пользователей и повышать их лояльность.
Когда заказчики обратились к нам, у них были наработки по фронтенду и готовый дизайн, который им не нравился. Они искали опытную команду, которая возьмется его переделать и довести до ума.
Этой командой стали мы, Purrweb. Хотя мы были не единственными кандидатами, заказчики в итоге выбрали нас: подкупила наша вовлеченность и структурированный подход — мы подробно объяснили, как будем работать, сделали понятный роадмап проекта, который попадал в сроки и бюджеты заказчика.
Не будем голословны, а просто покажем слайд из презентации для заказчиков — подробно расписываем все этапы работы и что конкретно делаем на каждом из них:
А вот и роадмап — четко декомпозировали задачи по спринтам:
Поначалу речь шла только о создании UI/UX дизайна для WAW. Но в итоге клиенты решили доверить нам еще и разработку бэкенда для приложения.
Об этом позже, а пока расскажем про фичи WAW, чтобы было понятно, как там все устроено.
Фичи WAW: как тут все устроено
Флоу приложения We’re all winners выглядит так:
Нам предстояло разработать удобный и простой дизайн, который бы соответствовал логике приложения, ожиданиям заказчика и потребностям целевой аудитории. Сейчас расскажем (и покажем!), как справились с этой задачей 🙌
Дизайн: подбираем палитру для яркого египетского солнца
Задача усложнялась тем, что у заказчика не было макетов в Figma, так что нам пришлось практически создавать дизайн с нуля — будем считать, что старого дизайна и не было 🙂
Тем не менее, кое-какие наработки заказчиков мы смогли использовать. Это некоторые компоненты из UI-kit, например, цветовая палитра для купонов. Еще был логотип, который мы взяли за основу и доработали по просьбе заказчика: им не нравилось прежнее визуальное решение.
Прежде чем лететь в разработку полноценного UI/UX, мы готовим дизайн-концепт: собираем референсы, определяем цветовую палитру, дизайним несколько ключевых экранов, чтобы отразить логику и визуальные решения.
Дизайн-концепт нужен для синхронизации с заказчиком: мы должны быть уверены, что находимся с клиентами на одной волне — это сократит количество правок, а значит, сэкономит бюджет заказчика.
Чтобы подготовить концепт, мы собираем референсы. Для WAW анализировали разные e-commerce приложения, доставки, лотереи и сайты по продажам купонов
Так выглядел наш дизайн-концепт: покажем несколько экранов.
А вот что получилось в итоге. Максимально близко к концепту: заказчику понравилось наше видение и реализация.
Эти же экраны в темной теме.
В качестве основного цвета интерфейса выбрали темный оттенок. Он хорошо контрастирует с белым фоном, не отвлекает внимание, а также будет заметен на экране даже в яркий солнечный день — актуально для Египта ☀️ Акцентным выбрали мягкий оранжевый цвет.
Цветовая палитра
Приложение доступно на двух языках, английском и арабском, поэтому создание UI на арабском могло бы стать челленджем. Но не стало 🙂 Это не первый наш заказчик из арабского мира, и мы уже знали, что нужно делать.
Мы адаптировали текст для чтения справа налево, увеличили кегль: в арабском нет заглавных букв, и шрифт может выглядеть мельче, чем на английском языке. Но это только часть работы 🙂 Мы учли много других важных деталей — подробнее о них рассказали в нашей статье про халяльный дизайн. На адаптацию интерфейса на арабский у нас ушло 20 часов.
Страница купона: английский и арабский
Еще мы сделали дизайн для лендинга приложения, включая респонсив-версию, и собрали гайдбук по стилю.
В гайдбуке собрали правила корпоративного стиля и айдентики, например, допустимое использование логотипа и цветовой палитры
Задизайнили для заказчика лендинг
На создание дизайна мобильного приложения, лендинга и гайдбука у нас ушло около 4 месяцев. Когда отдали готовый дизайн, заказчик принял решение остаться с нами 😀
Разрабатываем бэкенд на новой для нас технологии в супер-ускоренном режиме
За фронтенд-часть отвечала команда клиента, а нам предстояло взять на себя задачи по разработке бэкенда и админ-панели, хотя чаще всего мы делаем весь продукт целиком.
Конечно, работа с чужим кодом — это всегда немного вызов: кроме технической части, нужно еще наладить коммуникацию с разработчиками из команды клиента. Но для нас так работать не впервой — уже отточили подобный флоу на других проектах. Например, когда разрабатывали приложение для умных холодильников Vendify и CRM-систему для работы в полевых условиях (буквально!) для Koblik Group.
Сначала мы хотели делать бэкенд приложения WAW на своем обычном стеке NestJS. Но заказчик сказал, что так будет долго — не успеем. А успеть было важно: дата релиза уже объявлена, к ней привязывались маркетинговые активности и договоренности с вендорами.
Чтобы ускорить разработку, заказчик предложил использовать стек Firebase: он предлагает готовые решения. Мы никогда прежде не делали бэкенд на Firebase и решили, что это шанс освоить новую технологию.
Было одно но. Такое большое НО: мы оценили, что разработка займет 7 месяцев. Даже с учетом готовых решений от Firebase. И тогда…мы не успеем к дате, нужной клиенту. Как быть, что делать?
Нам невероятно нравился этот проект и мы не собирались сдаваться. Поэтому стали думать: а как еще возможно ускориться? И нашли решение.
Чтобы успеть к дедлайну, мы договорились с клиентом, что разделим все функции приложения на несколько фаз. Кроме того, мы сильно вывозили проект на своем энтузиазме и когда было необходимо, подключали еще ребят на помощь.
Времени глубоко погружаться в ресерч новой технологии не было, поэтому наши разработчики от теории тут же переходили к практике: изучили — внедрили, и это позволяло поддерживать быстрый темп.
Команда сплотилась и работала как конвейер. Забегая вперед, скажем: мы за 4 месяца успели то, что изначально оценивали в 7 месяцев.
Мы ожидали, что могут возникнуть сложности: все-таки работаем с новым стеком для бэкенда и новым типом базы данных Firestore. Но все прошло отлично и проблем не возникло.
Быстро разобраться с новой технологией нам помогла отличная коммуникация с командой клиента: с нами делились опытом и подсвечивали важные нюансы.
Инициативу проявил наш техлид — он выстроил регулярное общение с ответственным за техническую часть со стороны заказчика, который консультировал нас по Firebase.
Большинство вопросов мы решали на звонках, но разработчики — наши и со стороны клиентов, периодически переписывались в дискорде, если нужно было обсудить что-то «разработческое»
Еще плотно общались с фронтенд-разработчиками со стороны клиента, потому что было важно синхронизироваться в разработке. Конечно, это накладывало свои ограничения, но в итоге мы наладили хорошую коммуникацию, разделили зоны ответственности и вместе делали все, чтобы быстро разработать приложение.
Как все успеть к сроку и не выкидывать фичи? Расставить их по приоритетам
У заказчиков было много хотелок пожеланий по фичам, и если бы мы бросились разрабатывать все, везде и сразу, рисковали бы не успеть к дате релиза. Как все это учесть и не профакапить сроки?
Выкидывать фичи мы не могли, поэтому предложили другое решение, которое всех устроило: обозначили приоритет по каждой фиче, и на основе этого разделили версии приложения на четыре фазы.
Так выглядит таблица с фич-листом, где все функции расставлены по приоритетам
Объясним, как это работает. На этапе первой фазы, или тизер-версии приложения, мы запланировали всю базовую функциональность, с которой будем делать релиз. А дополнительные функции, у которых не такой высокий приоритет, решили добавлять потом, попутно получая фидбек от пользователей и хорошо понимая, как ведет себя приложение, что называется, в боевых условиях.
В релиз мы запускали именно тизер-версию приложения WAW. А затем перешли к разработке фич для второй фазы.
Пока основная команда работала над функциями второй фазы, мы подключили других наших ребят для разработки отдельного приложения-сканера купонов. Разделение труда позволило нам за это же время сделать дополнительный продукт — при этом не пришлось жертвовать разработкой новых фич для WAW.
Экраны приложения для сканирования купонов
Приоритизация задач сыграла ключевую роль: мы оптимизировали фич-лист, выделили необходимые функции для релиза, остальное перенесли на потом, чтобы успеть в срок.
Распутываем сложный флоу в админке
Создание админ-панели оказалось одним из главных вызовов на проекте, хотя, как говорится, ничего не предвещало 🙂
Обычно мы делаем админки на стеке React Admin. Это по сути конструктор с готовыми решениями, из которого можно максимально быстро собрать админ-панель. Быстро — значит, с экономией денег заказчика.
Так что преимущества такого подхода очевидны. Но есть и свои ограничения: у любого конструктора только базовый набор функций. Например, React Admin позволяет сделать админ-панель с такими фичами как управление пользователями, контроль прав доступа и менеджмент контента. Как правило, этого будет достаточно. Но если в админке нужно решать более сложные задачи, понадобится кастомная система.
Да, вы правильно поняли, к чему мы клоним 🙂 Именно такую кастомную систему нам пришлось пилить, используя при этом возможности конструктора React Admin для скорости.
Для начала объясним, почему в админке WAW такая сложная логика, а потом расскажем про наше решение. Обещаем, что не будем грузить вас всякими непонятными деталями!
WAW продает купоны, но условия их продажи могут сильно различаться. Чтобы описать эти условия, в системе создаются контракты — такие цифровые версии договоров. Контракт определяет все юридические аспекты продажи купонов в приложении — это важно для соблюдения законодательства.
Админ-панель WAW
Задача заключалась в том, чтобы все параметры контракта правильно отображались в приложении через админ-панель. У нас было 5 типов контрактов, каждый со своими уникальными условиями, которые нужно было корректно настроить в админке.
Сначала пошли по стандартному пути: сделали экраны админки на React Admin, но быстро поняли, что его возможностей недостаточно.
Чтобы сократить часы на разработку кастомной админки, решили сделать дизайн и разрабатывать по нему. Этот вариант позволил бы учесть всю сложную логику с контрактами.
Редактирование контрактов в админке
Обычно мы не отрисовываем экраны админки — берем готовые компоненты из React Admin, поэтому на этапе работы с дизайном не думали, что нам понадобится подготовить макеты.
Подключили UI/UX дизайнеров. Чтобы ребята учли все нюансы системы и ничего не пропустили, им помогали фронтенд-разработчик, системный аналитик и бэкенд-разработчики. В итоге не только справились с задачей, а еще и научились делать кастомные админки и выжимать максимум возможностей из конструктора React Admin 🤘
Страница для загрузки информации о призе
Без лишних апрувов и блокеров: как мы выстроили коммуникацию с заказчиком
На проекте мы выстроили четкую систему коммуникации с заказчиком и его командой разработки — это помогало двигаться с хорошей скоростью и не срывать дедлайны.
Нужно было держать клиента в курсе всех наших шагов и согласовывать решения, чтобы укладываться в сроки и соответствовать ожиданиям по бюджету.
Мы понимаем, что не всегда у клиента есть возможность оперативно выходить на связь, моментально отвечать на наши вопросы или давать апрув. Но если просто сидеть и ждать, когда клиент ответит, есть риск застопорить проект — совсем не то, чего мы хотим. Как быть? Действовать проактивно! 😼 Поэтому мы договорились с клиентом, что:
-
- Часть неключевых решений проджект-менеджер может принимать самостоятельно.
- Стратегические вопросы выносим на обсуждение с заказчиками.
- При необходимости проектный менеджер идет напрямую к главному лицу со стороны заказчика.
Если на этапе активной разработки коммуникация шла гладко, то на саппорте возникли сложности, и вот почему: человек из США, который принимал ключевые решения, отошел от дел. Арабская сторона порой медлила с принятием решений и сливалась не всегда была готова брать на себя ответственность. Это осложняло процессы.
Мы работаем с клиентами из самых разных стран, и понимаем, что у всех свои особенности менталитета и стиль ведения бизнеса. Так что мы выдохнули, приняли это как данность и стали думать, как нам быть. И нашли выход 🙂
Чтобы ускорить работу и меньше зависеть от согласований, мы договорились с основным лицом, принимающим решения, какие вопросы можем решать самостоятельно, без апрува.
We’re all winners растет очень быстро, а проблем с масштабированием нет
Мы не ожидали, что приложение окажется таким популярным и придет столько много пользователей — жители Египта оказались фанатами купонов.
Только в первые два месяца после релиза у нас было 73 тысячи активных юзеров. С каждым днем их становилось все больше — примерно на 500 человек в день.
Круто! Но мы опасались проблем с масштабированием — готовились к тому, что нужно будет больше мощностей. В итоге инфраструктура работает стабильно и выдерживает нагрузку. У нас ни разу не упал бэкенд, даже в самый пик. А заказчика настолько поразил наш профессионализм, что он отправил своего DevOps’а к нам на обучение на полгода 😀
Договариваемся с заказчиком об обучении DevOps’а
Небольшие трудности все-таки возникли, но мы нашли выход. Из-за стремительного роста популярности приложения у заказчика резко увеличились расходы на использование Google Auth — сервиса для отправки SMS-кодов при регистрации пользователей. Поэтому решили от него отказаться.
В сжатые сроки мы переписали функциональность авторизации, заменив Google Auth на интеграцию с местным SMS-провайдером. Так мы снизили затраты клиента и обеспечили стабильную работу системы без зависимости от сторонних сервисов.
Экран для входа по коду из SMS
За 4 месяца сделали то, что оценивали в 7 месяцев
Активную разработку мы начали в ноябре 2023 года, а первый релиз приложения в сторах состоялся в марте 2024 года — мы полностью уложились в сроки.
Помните, что изначально мы оценили работу в 7 месяцев? В итоге справились за 4 месяца — почти в два раза быстрее. Не в последнюю очередь благодаря мега-энтузиазму команды и огромной вовлеченности ребят, которые тащились от проекта 🤘
Заказчик был настолько доволен результатом, что мы смогли расширить объем работы и удвоить количество часов проекта.
Сейчас мы вышли в саппорт приложения — допиливаем фичи и фиксим мелкие баги.
Результат: 100k+ скачиваний, 130к юзеров за первые полгода и благодарные заказчики
Приложение We’re all winners доступно во всех сторах. WAW всего полгода, но за это время только в Google Play его скачали более 100 тысяч раз, а число активных пользователей перевалило за 130 тысяч.
Заказчик планирует расширяться и выходить на рынок Саудовской Аравии, в перспективе еще и Турция.
Недавно команда WAW приняла участие в масштабной конференции в Египте, где общалась с потенциальными вендорами и инвесторами — проект привлек много внимания.
Наши заказчики на конференции в Египте
И поблагодарили нас за огромный вклад: посмотрите, какие теплые слова написал клиент нашей команде 🥹
«Я знаю, что вы вложили много мыслей и всю свою душу в проект, поэтому делюсь этим моментом с вами, потому что вы заслужили быть его частью»
Этот проект наша гордость. Еще бы: и бизнес-задачи клиента круто решили, и сами прокачались как команда разработки 💪
Вот чему мы научились:
-
- делать архитектуру приложений на Firestore, с которым раньше не работали
- по максимуму использовать возможности React Admin — теперь сделаем любую кастомную админку
- подключать египетские платежные системы — а их тут было целых три, так что +3 в наш опыт работы с интеграцией локальных платежек
- и, как просили передать наши QA-инженеры, «выстраивать эффективное взаимодействие с Firebase через Postman и интегрировать это в наши автотесты», чтобы это не значило)
И напоследок еще одно сообщение от клиента — чтобы растопить ваши сердца 😭 ❤️
«По-настоящему прекрасно, что вы часть команды. Не могу представить, если бы мы работали над WAW и создавали приложение с кем-то другим»
➡️ Если вы хотите разрабатывать свой продукт не просто с ребятами, которые пишут код, а с теми, кто будет находить решения, не боится сложных ситуаций, знает, как выстраивать коммуникацию на проекте, чтобы достигать результата, то мы, Purrweb, здесь. Свяжитесь с нами, обсудим ваш проект и посчитаем, в какой бюджет обойдется разработка и сколько времени займет.
