Пряма мова. Head of Delivery w7g про інженерну культуру і технічні виклики SUITSME та FABU
- Катерина Шевченко
- 30 черв.
- Читати 7 хв
Оновлено: 5 днів тому

SUITSME і FABU — два продукти компанії w7g із власними унікальними механіками. Реліз першого відбувся у листопаді 2021 року, — і вже за два роки аудиторія сягнула 7 мільйонів гравців. Основа SUITSME — core-механіка одягання моделей, що поєднує кастомізацію, 3D-графіку й лайв-контент. 2024 року команда запустила новий продукт FABU, і сьогодні аудиторія вже двох продуктів — понад 25 мільйонів користувачів у світі.
На фоні кризи у геймдеві команді w7g вдалося не лише вижити у конкурентній ніші, а й зберегти стабільність продукту. Як будувати інженерну культуру, витримувати масштабування й працювати із технічними викликами, розповідає Ірина Ольховик, Head of Delivery w7g.
Під капотом SUITSME
Я приєдналася до команди SUITSME на етапі софт-лончу, коли архітектура продукту була вже закладена, і з того часу фундамент майже не змінився. Лише деякі технологічні рішення коригувалися, коли ставало зрозуміло, що вони недостатньо ефективні.
Спочатку використовували onion-архітектуру, у якій кожна частина відповідала за свій домен. У цьому підході логіка організована у вигляді шарів, які «обгортають» один одного. У центрі — core-домен (бізнес-логіка). Головний принцип — залежності спрямовані всередину, що робить систему стійкішою до змін. Згодом ми інтегрували MediatR для зменшення залежностей між модулями.
У SUITSME користувачі щодня проходять нові челенджі з одяганням моделей, які постійно оновлюються. Для цього потрібне seamless-завантаження, щоби навіть при великій кількості контенту гра залишалася швидкою й стабільною. Це реалізовано через Unity та C#. На клієнті для обміну даними в реальному часі використовується SignalR, що дозволяє синхронізувати ігрові стани. Завантаження графічного контенту налаштовано таким чином, щоби зображення могли оновлюватись у live-режимі: незакешовані текстури підтягуються через Unity Web Request Texture. На бекенді використовуємо стек із Entity Framework, ASP.NET та AWS.
Хоча архітектура SUITSME за цей час не зазнала радикальних змін, саме її надійність і правильна початкова структура дозволили продукту витримати масштабування — особливо у 2022–2023 роках, коли база користувачів та навантаження на систему стрімко зросли. Під ці зміни не довелося переписувати core — достатньо було правильно масштабувати інфраструктуру (інстанси, база, кеші).

Запуск FABU та пошук нового стеку
2023 року в Unity трапилася криза після гучної історії з Runtime Fee. Політика була незрозумілою, не було чітких відповідей щодо повторних інсталяцій, тому чимало компаній почали шукати альтернативи. w7g — не виключення, проте практичний досвід швидко показав: проблем з іншими рушіями не менше. Крім того, Unity згодом відкотила це рішення, а CEO Джон Річітелло пішов у відставку. Тому ми залишили SUITSME на Unity.
Саме в цей період у нас народилася ідея нового продукту — FABU, застосунку, який допомагає відстежувати та аналізувати настрій, і виражати емоції через моду. Для нього ми вирішили протестувати новий стек. Proof of Concept був написаний на React Native. Проте з’ясувалося, що цей фреймворк React Native не підходить для такого функціоналу: він має обмежені можливості для роботи з 2D-графікою, слабку підтримку blend mode, і не підтримує повноцінно 2D canvas. Перші прототипи виявились нестабільними — моделі та елементи одягу відображались некоректно, фони злипались, а маски працювали з помилками.
Тоді розробник спробував реалізувати ідею на Flutter із Flame-рушієм. Результат виявився набагато кращим — механіка працювала коректно, і команда вирішила продовжити розвивати продукт на цьому стеці.
Нам вдалося перевикористати контент (на той момент понад 15 тисяч одиниць одягу), а також частину серверної логіки SUITSME — зокрема, обробку платежів. Це дало змогу швидко стартувати з новим продуктом.
Для керування станом використовується BLoC (flutter_bloc, bloc_concurrency), а інʼєкція залежностей реалізована через get_it та injectable. Для мережевих запитів застосовується Dio, аналітика й моніторинг працюють на сервісах Firebase (analytics, crashlytics, performance, remote_config, app_check). Також використовуються утиліти для локалізації (intl), кешування зображень (cached_network_image) й інші пакети, що допомагають підтримувати стабільну й гнучку архітектуру продукту.

Unlock new level — веб
Спочатку продукт SUITSME був орієнтований лише на мобільні платформи — Google Play та Apple Store. Згодом команда побачила потенціал у вебверсії, адже з'явилися користувачі, які активно грали у браузерні ігри.
Ми вирішили спробувати запустити вебверсію на WebGL. Спершу здавалося, що основний core можна легко перенести, адже вся механіка була вже реалізована на Unity.
Але коли справа дійшла до плагінів та бібліотек, покупок та обробки сапорт-листів, — довелося їх переписувати практично з нуля. Ще й до того, підтримувати дві логіки одночасно. Наприклад, обробка покупок у мобільних версіях відбувається через сервіси Google та Apple, а вебпокупки — через іншу платформу. Звʼязок із сервером відбувається через http, а в мобільних версіях — через signalR.
Проєкт вийшов складнішим і довшим, ніж очікували, але врешті команда успішно запустила вебверсію, і це дало перевагу над конкурентами SUITSME. Частина аудиторії активно користується саме браузерною грою. Зараз вона повністю підтримується: усі оновлення відбуваються одночасно з мобільними версіями. Це доволі нестандартне рішення для такого типу ігор як SUITSME, але там живе частина аудиторії, якій десктопне рішення подобається.
Як пережити стрімке зростання live-продукту без критичних крашів
У 2022–2023 роках SUITSME почав стрімко зростати за кількістю користувачів і навантаженням на систему. Це призвело до перших серйозних технічних викликів: почали з’являтися неочікувані даунтайми, особливо у пікові години, коли користувачі з США масово заходили у гру. Команда швидко відреагувала: почали масштабувати базу даних, піднімати додаткові серверні інстанси, щоби краще обробляти пікові навантаження.
Полегшенням для команди стало створення MVP адмінки — системи для віддаленого керування челенджами, завантаження контенту (одягу, зачісок, мейкапів). У ній зʼявилися правила автоматичної валідації, а до цього доводилося перевіряти весь контент вручну після кожного заливання. Надалі система ставала складнішою: зараз через неї нараховують нагороди учасникам за участь у live-івентах, керують сезонами та анонсами.
Разом із командою аналітики ми налаштували технічний дашборд. Після кожного дейлі відкриваємо його і переглядаємо ситуацію в динаміці — як за останню добу, так і за 30-100 днів. Щоби виявляти проблеми з челенджами, налаштували окремі алерти — наприклад, якщо розрахунок триває понад 10 хвилин або щось не так із дрес-кодом, система сповіщає команду. Окрема зона уваги — транзакції. Якось виявили, що через перевищення ліміту по вебхуках у Google деякі покупки не фіксувалися в базі. Тепер і на такі кейси налаштовані алерти.
Особливу увагу приділяємо швидкості завантаження застосунку. Є два критичні API-запити: один — для новачків, другий — для активних користувачів. Обидва моніторяться на предмет швидкості відповіді. Якщо бачимо спайки, перевіряємо, чи є проблеми на стороні сервера — зокрема за кількістю помилок 400/500.
Формально SLA з кількістю «девʼяток» не встановлювали, але орієнтуємося на 99.99% стабільності (близько 53 хв даунтауму на рік). Одноразова планова недоступність не має перевищувати 20-30 хв. Проте це не завжди вдається — при нещодавньому оновленні на .NET 9 система була недоступною близько години. Підготовка до таких великих релізів починається заздалегідь і включає не лише технічні задачі. Контент-менеджери готують попередження для користувачів у грі й на сторінках спільноти. На час даунтайму виставляється заглушка, яка повідомляє про технічні роботи. У Facebook-спільноті публікуються пости, щоб користувачі розуміли, що відбувається.
Важлива синхронізація між командами. Кожен знає свою роль: хто відповідає за оновлення клієнта, хто за відкриття доступу, хто перевіряє стабільність після оновлення. Процес задокументовано з детальними кроками, щоб кожен учасник точно знав, що і коли потрібно зробити. Це дозволяє зберігати контроль навіть у складних релізах із багатьма залежностями.

Failed => Retried => Learned
У розвитку продуктів у команди SUITSME та FABU було кілька невдач, які згодом стали важливими уроками. Один із них — випадковий реліз драфтового одягу, який трапився декілька років тому. В адмінці гри є одяг, який не відображається звичайним користувачам — він призначений для внутрішнього тестування фешн-командою. Через помилку цей драфтовий контент потрапив у продакшн і став доступним усім. Це сталося у суботу ввечері. Хтось із користувачів помітив нові речі — весільні фати й сукні — й почав обговорення у Facebook-спільноті. Команда швидко зреагувала: видалили ці речі з доступу, налаштували комунікацію, повернули користувачам витрачені кошти, щоби згодом вони могли придбати ці елементи повторно вже після офіційного запуску. Після цього в регресійний цикл додали обовʼязкову перевірку на наявність драфтових елементів перед релізом.
Ще один кейс — втрата важливого документа з правилами масок і шарів одягу, який зберігався в одного зі співробітників. Коли постала потреба в оновленні масок після оптимізації контенту, зʼясувалося, що файл недоступний. Частину інформації вдалося відновити, але після цього команда впровадила правило обовʼязкової передачі всієї технічної документації при виході співробітника.
Інший виклик — баг із преміальними нагородами, які не нараховувались користувачам після одного з релізів. Помилку помітили завдяки скаргам уночі, і проблему вдалося виправити та випустити оновлення менш ніж за 6 годин.
Кожен із цих кейсів сформував у команді культуру відкритого аналізу помилок і впровадження змін у процеси. Тепер важливі перевірки автоматизовані, документація зберігається централізовано, а процеси релізів включають додаткові запобіжники.
Невдала спроба — новий процес
Один з найбільших фокусів команди сьогодні — оптимізація часу завантаження SUITSME. Зі зростанням продукту та кількості контенту, ця проблема стала більш помітною.
Різниця в 1 секунду може впливати на рішення користувача — залишитись у грі чи закрити її. За даними дослідження Mobile User Expectations in 2025, 61% користувачів не готові чекати більш ніж п'ять секунд, поки мобільний застосунок запуститься, а 20% очікують, що це буде зроблено за дві. Кожна додаткова секунда значно підвищує ризик втрати користувача. Особливо це критично для casual-ігор і лайфстайл-продуктів, де конкуренція за увагу дуже висока.
Щоби виправити ситуацію, команда запланувала серію значних змін у підходах до завантаження на початку року. План складався з трьох великих етапів, кожен із яких мав зайняти близько тижня-півтора. Вирішили переписати систему завантаження на асинхронні кроки, серед яких були критичні та некритичні для відображення контенту та механіки гри. Якщо один із некритичних кроків зафейлиться, система не показувала користувачу помилку, а продовжувала завантаження.
На практиці ця система не дала значних переваг, і час завантаження не став меншим, хоча незначні помилки вдалося вирішити. Це стало серйозним внутрішнім викликом: команда ретельно проаналізувала, чому погодились на рішення, яке не принесло ефекту. Відтоді усі нові гіпотези щодо оптимізації завантаження проходять через детальний аналіз переваг і ризиків та тестування ефективності. Якщо ризики переважають або результат невизначений, рішення не береться в роботу. Усі наступні покращення впроваджують обережно й поетапно.

Процеси, що тримають ремоут
До повномасштабного вторгнення команда працювала у змішаному форматі: частина людей була в офісі, частина — на ремоуті. Після 2022 року ремоут став новою реальністю: частина людей переїхала в інші міста чи країни. Повернути всіх в офіс було неможливо, і w7g стала full-remote компанією.
Команда швидко адаптувалася. Усі процеси перевели в публічні чати: навіть якщо питання обговорюють два-три спеціалісти, воно фіксується в загальному каналі, щоб команда бачила й могла підключитися. Так зберігається фокус і прозорість — будь-хто може знайти потрібну інформацію. Дрібні питання вирішують через короткі мітинги, щоби не затягувати комунікацію листуванням. Водночас команда свідомо відмовилась від мікроменеджменту: не використовуємо трекери часу, щоби контролювати, скільки хто «рухає мишкою», а просто даємо людям відповідати за свої задачі.
Ця культура довіри й прозорості допомогла зберегти стабільність у роботі навіть у складні періоди. Кожен розуміє, чим важлива його робота для загального результату, і має можливість самостійно керувати своїм часом і навантаженням. Це створює атмосферу, у якій команда швидко приймає рішення й залишається ефективною навіть у повному ремоуті.

Ріст, менторство і внутрішній вплив
Від початку команда будувалася з мідл- і сеньйор-спеціалістів. Це дало змогу створити культуру, у якій джуни та трейні, які приєднувалися пізніше, могли швидко вчитися. Усі нові люди отримують підтримку: на етапі онбордингу чітко зрозуміло, хто допомагає, відповідає на питання, передає знання. Це працює не як формальна менторська програма, а як природна частина командної культури.
Якщо є питання до якості роботи, це обговорюється відразу. Культура відкритого фідбеку дає змогу швидко реагувати й розвиватися. Раз на пів року проходять ревʼю, де обговорюються зони росту, у яких спеціаліст може розвиватися.
Кожен має доступ до ключових метрик — ретеншн, монетизація, поведінка користувачів — і може бачити, як зміни впливають на загальні результати. У команді немає барʼєру «твоя зона — тільки QA або тільки розробка». Якщо ідея корелює з цілями продукту, її впроваджують. Можливість вести фічу «під ключ» — від ідеї до продакшену — дає відчуття відповідальності та створює здорову атмосферу, де кожен відчуває, що його думка важлива, і є простір для розвитку.