← Все статьи

Как мы делали WhatToDo: от идеи до публичного релиза в Google Play и RuStore

История разработки WhatToDo: гипотеза, MVP за 6 недель, закрытый тест в Google Play и выход в открытый доступ 1 августа 2026. Стек, решения, ошибки и выводы.

whattodo разработка продукт

Контекст

WhatToDo — наш собственный продукт. Мы 3VStyle, Laravel-студия, и параллельно с клиентскими проектами делаем приложение «Чем заняться?».

Идея простая: помочь быстро решить, чем заняться сегодня вечером, — без переписки и споров. Ниже полный путь: от гипотезы и MVP через закрытый тест до публичного релиза 1 августа 2026 года в Google Play, RuStore и вебе.

Гипотеза

Главный инсайт мы получили на собственной паре. На «что посмотрим?» в пятницу вечером уходит до 40 минут переписки. И самое интересное — проигрывают оба: смотрят не то, что хотел один, и не то, что хотел второй.

Гипотеза: если двое выбирают не словами, а свайпами — конфликт пропадает. На совпадении уже не надо обсуждать.

Это не оригинальная механика — Tinder и его форматы делали то же для других задач. Оригинальная часть — применить её к выбору общих идей и довести совпадение до конкретного плана.

MVP за 6 недель

Мы намеренно ограничили MVP минимумом:

  • одна комната (пара = 2 устройства);
  • одна колода карточек на 30+ идей;
  • сценарий «открыли — свайпнули — увидели совпадение»;
  • никаких профилей, статистик, push-уведомлений на старте.

Принципиально не делали:

  • библиотеку идей с фильтрами;
  • аналитику пользователя;
  • premium-фичи.

Цель MVP — проверить, что сама механика работает. Всё остальное — после теста гипотезы.

Стек

Слой Решение Почему
Frontend Vue 3 + Vite Быстрый старт, хорошие dev-tools, привычный нам
Стейт-менеджер Pinia Минимум boilerplate, удобный TypeScript
Realtime + auth + db Supabase Postgres + готовый realtime + auth «из коробки»
Push, analytics, crash Firebase (FCM + Analytics + Crashlytics) Стандарт для Android, нативные SDK
Места и маршруты Google Places Готовая база заведений вместо своей
Упаковка под Android Capacitor Web-bundle превращается в нативный APK/AAB
CI/CD GitHub Actions + Capacitor build Один пайплайн от Vite-build до .aab

Подробнее про архитектуру и реалтайм-механику — в отдельной статье.

Решения, которые сэкономили нам время

  • Supabase вместо своего бэкенда. Это типичный SaaS-сценарий: 1 человек на стек вместо 3. Чужой Postgres, чужой auth, чужой realtime — а у нас полный контроль над схемой.
  • Capacitor вместо Flutter/React Native. У нас сильная web-команда. Не было смысла учить новый язык и нативные тулчейны ради приложения, ядро которого — экран свайпа. Бонус, который мы недооценили: та же кодовая база дала веб-версию практически бесплатно.
  • Google Places вместо своей базы мест. Собирать и поддерживать справочник заведений — отдельный продукт. Мы его не делали.
  • Firebase для базовой телеметрии. Crashlytics обязателен для closed test — без него Play Console показывает crash rate слишком грубо.

Решения, которые мы пересматривали

  • PWA vs Capacitor. Сначала пробовали жить как PWA. Не подошло: на Android установка PWA пугает пользователей, иконка теряется, Play Store предпочитают сами. Перевели проект в Capacitor.
  • Только пара vs соло и группы. Мы строили продукт «для двоих». В закрытом тесте выяснилось, что люди открывают приложение в одиночку — просто чтобы выбрать себе занятие, — и зовут компанию друзей. К релизу режимов стало три: соло, пара, группа (до 4 человек бесплатно и до 10 в Premium).
  • Ссылки-приглашения вместо кодов. Первый вариант подключения второго участника — код комнаты. Каждый шаг с ручным вводом стоил нам части пар. Заменили на ссылку с Android App Links: партнёр переходит и сразу попадает в сессию.
  • TTL сессии. Первый вариант — комната живёт «вечно». Это мешало UX: вернувшись через неделю, пара видела свои же старые свайпы вместо чистого старта. Сделали ограниченное время жизни сессии.
  • Что делать, если совпадений нет. Изначально «нет матча» = конец сессии. Это худший из возможных финалов: люди потратили время и остались там же, где начали. Добавили режим переговоров — приложение показывает варианты, которые были ближе всего к общему интересу.

Что было сложно

  • Синхронизация двух устройств через Supabase realtime. Сценарий «один свайпает offline, второй online» решали через локальный кеш и репликацию при возвращении в сеть.
  • Бюрократия сторов. Политика конфиденциальности и инструкция удаления аккаунта должны быть на отдельных публичных URL, content rating нужно подтверждать, скриншоты — со строгими форматами. RuStore добавил свой цикл проверок, и закладывать на него «пару дней» не стоит.
  • Платежи в трёх контурах. Google Play даёт свой биллинг, но он не покрывает RuStore и веб. В итоге сделали три канала: Google Play, Telegram Stars для RuStore и веба, и промокоды. Это заметно больше кода, чем «просто подключить подписку».
  • «Чем меньше — тем сложнее». MVP с 5 экранами требует не меньше дисциплины, чем приложение с 50 экранами. На каждый «давай добавим…» отвечали «нет, не в MVP».

Чему научил закрытый тест

Закрытый тест был не про поиск багов — баги ловит QA. Он был про то, чего мы не видели изнутри.

  • Первая сессия важнее всех остальных. Если пара не дошла до первого совпадения за пару минут, второго запуска не будет. Всё, что стояло между установкой и первым матчем, мы вырезали или ускорили.
  • Совпадение — это ещё не результат. «Вы оба хотите поужинать вне дома» звучит хорошо ровно до вопроса «а где?». Отсюда выросли места рядом через Google Places и маршрут.
  • Возвращаемость держится не на механике, а на смысле. Люди возвращаются, когда видят, что у них что-то накапливается. Так появились совместная статистика и стрики, 13 достижений и Weekly Wrapped.
  • Одна колода — это скучно на третий вечер. Пришлось развести контент по ситуациям: вечер, выходные, экстрим, отпуск, еда и напитки, ночной сет. Плюс кастомизация колод и отдельный кино-режим.
  • Люди хотят играть, а не только планировать. Отсюда shake и режим сюрприза, где один партнёр собирает план, а второй узнаёт его в момент выхода.

Что вышло в публичный релиз

К 1 августа 2026 приложение — это уже не MVP:

  • три режима: соло, пара, группа;
  • тематические колоды и настройка колод;
  • матчи в реальном времени и режим переговоров;
  • места рядом и маршрут;
  • приглашения по ссылке, shake, кино-режим, режим сюрприза;
  • статистика пары, стрики, 13 достижений, Weekly Wrapped, вишлист;
  • push и внутренние уведомления, русский и английский, вход через Google;
  • Premium: расширенные фильтры, увеличенные колоды, безлимитные контакты и повторные свайпы, премиальные палитры и анимации.

Что это значит для пользователя и где скачать — в статье про запуск.

Что планируем дальше

  1. Публичный запуск — сделано 1 августа 2026: Google Play, RuStore и веб-версия.
  2. iOS-версия — на той же кодовой базе через Capacitor.
  3. Больше тематических колод. «Дождь на улице», «нет сил», «давно никуда не выходили».
  4. Развитие групповых сценариев. Группа ведёт себя не как пара: там другая динамика согласия.
  5. Глубже в план. Совпадение должно доводиться до конца — бронь, время, напоминание.

Если вы запускаете свой MVP

Несколько практических выводов:

  • Закрытый тест — лучшая школа продукта. Двадцать настоящих пар покажут то, чего не покажут двести внутренних прогонов.
  • Между MVP и релизом лежит больше работы, чем между идеей и MVP. MVP отвечает на вопрос «работает ли механика». Релиз отвечает на вопрос «вернутся ли люди завтра», и это совсем другая работа.
  • Дистрибуция — часть продукта. Google Play, RuStore и веб — это три разных набора требований, биллингов и сроков проверки. Планировать их стоит заранее, а не за неделю до релиза.
  • Идея «всё в одном» убивает старт. Лучше одна простая механика, доведённая до конца, чем четыре половинчатые.

Если такое нужно вам как сервис — мы делаем подобные проекты под клиентов. Если интересно следить за процессом — заходите в Telegram-канал WhatToDo.

Что почитать дальше