Розробка мобільного додатку: що має бути в кейсі замість каталогу екранів

Коротка відповідь: типовий кейс мобільної розробки це десять гарних скриншотів і фраза «запустили в строк». Замовнику це майже нічого не каже, бо екрани може намалювати будь-хто, а перевірити, хто і як робив застосунок, по них неможливо. Корисний кейс показує задачу, найскладніше рішення, як тестували, що пішло не так і що можна перевірити в магазинах самому.

Нижче як це виглядає на нашому проєкті Qela, застосунку для спільнот на iOS та Android. Усі цифри з трекера задач і публічних карток магазинів станом на 6 жовтня 2026 року.

Задача, а не перелік функцій

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

Звідси головна умова, яку жоден скриншот не покаже. Якщо завдання можна «виконати», не вийшовши з дому, ламається і голосування, і система нагород. Тобто застосунок мав не просто показувати квести, а збирати доказ, що квест справді виконано.

Саме з цього має починатись кейс: з умови, яка визначила архітектуру, а не з переліку екранів.

Найскладніше рішення

Квестів десять типів: опитування, вікторина, петиція, донат, доставка, публічний виступ, відгук, відвідування зборів, онлайн-зустріч, завантаження фото. Одна кнопка «готово» на всі не працює.

Тому кожен тип отримав свій доказ.

Компроміс тут справжній. Перевірка адміністратором коштує організації часу модераторів, а учасник довше чекає нагороду. Тому частину перевірок застосунок робить сам: радіус і QR-код.

Як тестували: цифри, а не «ретельно»

Два нативні застосунки писали паралельно двоє розробників: Android на Java, iOS на Swift. Тестували платформи окремо.

Одна знахідка з тестування варта окремого рядка в кейсі. Квест, який чекав рішення адміністратора, можна було пройти ще раз. Без блокування одна дія могла б принести нагороду двічі. Повторне проходження заблокували, доки рішення немає.

Це саме те, що відрізняє кейс від презентації. Помилку видно, причину видно, і видно, як її закрили.

Що ми прибрали зі старої версії кейсу

Окрема історія, і нам за неї не дуже приємно.

Попередня версія цього кейсу, березень 2025 року, стверджувала три речі. Що захист даних гарантує конкретна хмарна платформа. Що в застосунку закладено Bluetooth і NFC. Що Android-версія написана на Kotlin.

Коли ми цього жовтня переробляли кейс і звіряли кожне твердження з трекером задач, жодне з трьох не підтвердилось. Android-версія написана на Java. Тому в новій версії ці твердження прибрані, а в кейсі прямо написано, що саме прибрано і чому.

Мораль для замовника: якщо в кейсі агенції є технічні деталі, спитайте, звідки вони. Ми самі тримали в кейсі непідтверджені твердження понад рік, і ніхто не спитав.

Що зробили б інакше

Три речі, і всі три корисні тим, хто планує схожий застосунок.

Перевірку виконання проєктувати першою. Повторне проходження квесту на перевірці знайшли в тестуванні, а не на етапі проєктування. Так само з відмовою в дозволі на геопозицію: спершу вона просто блокувала квест без повторного запиту.

Закладати етап розвитку після першого релізу. Обсяг ріс у процесі, і частину функцій оформлювали як додаткові роботи.

Обидві картки магазинів на акаунтах клієнта. У нашому випадку застосунок в App Store виходить від імені клієнта, а в Google Play з пакетом агенції. Google Play дозволяє перенести застосунок між акаунтами розробників без втрати історії встановлень, і це варто закласти в план передачі проєкту з першого дня.

Що можна перевірити самому

Найкращий тест кейсу: чи можна перевірити хоч щось без агенції.

У цьому випадку можна. Застосунок є в App Store з 16 травня 2024 року, версія 1.31 вийшла 21 січня 2026-го, оцінка 4,67 за 12 оцінками. У Google Play понад 500 встановлень, оновлення 9 вересня 2026 року. Інтерфейс чотирма мовами.

Чого в кейсі немає

Ми не маємо бізнес-метрик: кількості спільнот, активних учасників, виконаних квестів. Клієнт їх не оприлюднював, тому в кейсі їх немає, і ми не підставляємо оцінок.

Немає й метрик стабільності з консолей магазинів. Порівняння «до і після» теж немає, бо як спільноти працювали до застосунку, у матеріалах не описано.

Часті питання

Що має бути в кейсі мобільної розробки?

Задача, яка визначила архітектуру, найскладніше рішення, цифри тестування, помилки й що з ними зробили, і дані, які можна перевірити в магазинах.

Як перевірити кейс агенції?

Знайти застосунок у магазинах, подивитись дату першого релізу, останнього оновлення і розробника в картці. Спитати, звідки технічні деталі.

Чому важливо, на чий акаунт опублікований застосунок?

Від цього залежить, хто контролює застосунок після завершення співпраці. Найпростіше, коли обидві картки на акаунтах замовника.

Скільки тривала розробка?

Від першої задачі в трекері до першого релізу в App Store минуло 11 місяців. Супровід триває досі.

Підсумок

Кейс мобільної розробки корисний тоді, коли показує не екрани, а рішення. На прикладі Qela це десять типів квестів, кожен зі своїм доказом виконання, 782 баг-репорти з розбивкою за платформами, лазівка з подвійною нагородою, знайдена в тестуванні, і три непідтверджені твердження, які ми прибрали з власної старої версії кейсу.

Замовнику варто питати саме про це. Що було найскладнішим, як тестували, що пішло не так і що можна перевірити в магазинах без агенції.

Матеріал підготували Євгеній Чиж, засновник Chyzh Agency, і Сергій Колодинський, Head of Mobile Development.