Вопросы к основателю Nukl

Данный документ содержит структурированные вопросы, ответы на которые необходимы для формирования точной стратегии развития продукта. Каждый вопрос сопровождается обоснованием и анализом возможных ответов.

1. Бизнес-вопросы

1.1 Целевой рынок: какой город/страна первый?

Зачем: От выбора первого города зависит весь playbook запуска — язык контента, каналы привлечения, юридические требования, партнёрства с полями, бюджет. Исследование показало, что гиперлокальный запуск — единственный рабочий подход для двусторонних маркетплейсов.

Варианты и их implications:

• Город в России/СНГ — большой незанятый рынок после ухода западных платформ, но геополитические риски, ограниченный доступ к западным платёжным системам (Stripe), App Store ограничения. Локализация на русский уже есть.
• Город в Европе (Испания, UK, Нидерланды) — высокая футбольная культура, платёжеспособность, доступ к Stripe/RevenueCat, но сильная конкуренция (Footy Addicts, Plei, Playtomic). Нужен отдельный маркетинг-бюджет.
• MENA (Дубай, Эр-Рияд) — Vision 2030, молодое население, мало конкурентов, высокий ARPU. Но нужна арабская локализация и понимание культурных особенностей.
• Латинская Америка — огромная футбольная база, растущая digital-penetration, но низкий ARPU, нужна локализация на португальский.

1.2 Бюджет: сколько можно потратить до первого дохода?

Зачем: Определяет количество городов для запуска, размер команды, возможность субсидировать капитанов и поля. Финансовая модель показывает минимум $120-200K на 8 месяцев до PMF.

Варианты:

• < $50K — только один город, solo-founder, минимальный маркетинг. Реалистично, но очень медленный рост. Потребуется bootstrapping и личное участие как "капитана".
• $50-200K — 1-2 города, маленькая команда (2-3 человека), базовый seeding. Достаточно для проверки PMF.
• $200-500K — pre-seed уровень, 2-3 города, полноценная команда, субсидии для полей. Оптимальный сценарий.
• $500K+ — seed-раунд, агрессивный рост на 5+ городов. Требует привлечения инвестиций.

1.3 Timeline: когда нужен публичный запуск?

Зачем: Create Match — заглушка "Coming soon", а это единственный критический блокер. Без понимания дедлайна невозможно расставить приоритеты: закрывать техдолг или гнать фичи.

Варианты:

• "Вчера" / ASAP — тогда запускаемся с Create Match как MVP (минимальная форма) за 2-3 недели, техдолг откладываем.
• Через 2-3 месяца — полноценный Create Match + чат + invite-ссылки + аналитика. Оптимальный набор.
• "Когда будет готово" — можно закрыть весь Phase 1 roadmap (15 недель), включая CI/CD и техдолг.
• К определённому событию (начало сезона — сентябрь, весенний подъём — март) — привязка к сезонности даёт естественный push.

1.4 Команда: кто ещё работает над проектом?

Зачем: Код демонстрирует уровень senior-разработчика (триггеры, RLS, PostGIS, Edge Functions). Но для Phase 1 roadmap (15 недель) одному человеку потребуется 4+ месяца. Наличие команды определяет параллелизм задач.

Варианты:

• Solo-founder — все задачи последовательно, приоритет на Create Match, всё остальное — потом. Рекомендация: AI-ассистенты для ускорения, фокус только на core loop.
• Founder + 1-2 разработчика (part-time) — возможна параллельная работа над фичами и техдолгом. Нужна чёткая декомпозиция задач.
• Полноценная команда (3-5 человек) — Phase 1 можно закрыть за 2-3 месяца. Нужны процессы (CI/CD становится критичным), code review.
• Founder + дизайнер + разработчик + маркетолог — идеальный состав для стартапа. Дизайнер нужен для Create Match flow и карточек шеринга.

1.5 Амбиции: lifestyle business vs venture-backed?

Зачем: Это фундаментальное решение, от которого зависит скорость роста, готовность к риску, подход к монетизации и burn rate. Финансовая модель описывает сценарии от $200K до $2.5M инвестиций.

Варианты:

• Lifestyle business — самоокупаемость как приоритет, органический рост, 1-3 города, подписка как основной доход. Меньше стресса, но медленный рост и риск проиграть конкурентам.
• Venture-backed — агрессивный рост, pre-seed $200-350K, 10+ городов за 2 года, маркетплейс площадок. Больше шансов на доминирование в нише, но размывание долей, давление инвесторов.
• Гибрид — начать как lifestyle, доказать PMF, затем привлечь инвестиции с сильными метриками. Самый безопасный путь.

1.6 Юридическое лицо

Зачем: Необходимо для Apple/Google developer accounts, Stripe, договоров с площадками, обработки персональных данных (GDPR). Сайт nukleball.com уже есть (ссылка в коде), legal-страница существует.

Варианты:

• Уже зарегистрировано — уточнить юрисдикцию (влияет на налоги, Stripe availability, GDPR compliance).
• Ещё нет — рекомендация: US LLC (Delaware) для глобального запуска или EU (Эстония e-Residency, Нидерланды) для европейского фокуса.

1.7 Конкуренты: кого считаете главным конкурентом и почему?

Зачем: Исследование выявило 12+ конкурентов, но ни один не доминирует глобально. Понимание того, с кем основатель себя сравнивает, показывает реальное позиционирование и амбиции.

Варианты:

• Footy Addicts / Plei — прямые конкуренты в pickup-футболе. Значит, фокус на лучший UX и геймификацию.
• Spond / TeamSnap — конкуренты в team management. Значит, фокус на организованные команды, не только pickup.
• WhatsApp-группы — главный "конкурент" — неэффективные чаты. Значит, фокус на замену мессенджеров для организации матчей.
• Playtomic — вдохновляющий конкурент из ракетных видов. Значит, фокус на marketplace площадок.

2. Продуктовые вопросы

2.1 Если бы можно было добавить только ОДНУ фичу прямо сейчас, какую?

Зачем: Выявляет интуицию основателя о главном блокере. Аудит показывает, что Create Match — критический блокер, но основатель может видеть иначе (например, чат или оплата).

Варианты и implications:

• Create Match — согласен с аудитом, фокус на разблокировку органического роста.
• Чат — считает, что коммуникация важнее организации. Возможно, пользователи уже организуют матчи через админку, а им не хватает общения.
• Оплата/сплит — главная боль — "собрать деньги", а не "собрать людей". Меняет приоритет монетизации.
• Лидерборды/статистика — верит в геймификацию как retention-драйвер. Значит, уже есть база пользователей, которых нужно удерживать.

2.2 Каким вы видите Nukl через 2 года?

Зачем: Определяет направление развития: от pickup-приложения до полноценной спортивной платформы. Влияет на архитектурные решения прямо сейчас.

Варианты:

• "Uber для футбола" — матч в один тап, marketplace площадок, автоматический matchmaking. Фокус на технологию.
• "Strava для футболистов" — социальная сеть с глубокой статистикой, рейтингами, достижениями. Фокус на данные и community.
• "WhatsApp-killer для спорта" — чат + организация + оплата, замена мессенджеров. Фокус на коммуникацию.
• "Playtomic для футбола" — бронирование полей + организация матчей, B2B + B2C. Фокус на marketplace.

2.3 Какие приложения считаете эталоном UX?

Зачем: Помогает понять вкус основателя и направление дизайна. Текущий UI уже продуманный (pill-shaped кнопки, dark/light тема, скелетоны, haptic feedback), но дизайн-система может развиваться в разных направлениях.

2.4 Что больше всего раздражает в текущем состоянии приложения?

Зачем: Основатель ежедневно пользуется продуктом и видит friction, который не виден в аудите кода. Это конкретные UX-проблемы, которые можно быстро исправить.

2.5 Create Match: почему заглушка? Какие конкретные блокеры?

Зачем: Это самая критическая функция в продукте. Заглушка "Coming soon" может означать: (а) не дошли руки, (б) сложная бизнес-логика создания матча не до конца проработана, (в) нет партнёрств с полями для бронирования, (г) сознательное решение контролировать качество матчей через ручное создание.

Варианты:

• "Просто не дошли руки" — можно начать реализацию немедленно. Схема БД (matches, fields, match_players) уже готова.
• "Нет UX-дизайна" — нужен дизайнер или wireframes. Блокер — дизайн, не код.
• "Не хочу давать всем создавать матчи" — модерируемая система. Тогда нужен flow "заявка на матч" -> одобрение админом.
• "Нужна интеграция с площадками" — блокер — бизнес-партнёрства. Рекомендация: начать без бронирования, просто указание адреса.

2.6 Чат: планировался?

Зачем: В коде NotificationRouter есть case 'chat' — заглушка для чата. Supabase Realtime уже используется для уведомлений и друзей. Чат — вторая по приоритету фича после Create Match в RICE-скоринге.

Варианты:

• "Да, планировался, но не успели" — можно начать реализацию на Supabase Realtime, инфраструктура готова.
• "Нет, пусть общаются в WhatsApp" — тогда нужна интеграция с мессенджерами (deep links в WhatsApp-группу матча). Но это отдаёт коммуникацию из приложения.
• "Только после Create Match" — логичная последовательность, чат без возможности создать матч не имеет смысла.

2.7 Монетизация: уже думали о модели? Есть предпочтения?

Зачем: Исследование рекомендует гибридную модель (бесплатно -> подписка -> marketplace -> B2B), но основатель может иметь принципиальную позицию (например, "навсегда бесплатно" или "подписка с первого дня"). В схеме БД уже есть price_cents и currency в таблице matches — это осознанное решение?

3. Вопросы о пользователях

3.1 Есть ли уже пользователи? Сколько? В каком городе?

Зачем: Это определяет, на какой стадии находится продукт: pre-launch (0 пользователей, всё теоретически) или early traction (есть реальные данные). Версия приложения 1.0.0+14 (14 билдов) и наличие news feed с контентом намекают на существующую базу.

Implications:

• 0 пользователей — чистый pre-launch. Приоритет: Create Match + первый город + seeding.
• 10-50 пользователей — тестовая группа друзей/знакомых. Приоритет: собрать feedback, понять friction.
• 100-500 пользователей — ранний traction. Приоритет: retention-метрики, аналитика, понять unit economics.
• 500+ — серьёзная база. Приоритет: масштабирование, монетизация, второй город.

3.2 Какой feedback от первых пользователей?

Зачем: Система feedback уже реализована (bug/idea/other с rate-limiting 20/день). Если есть реальные отзывы — это золотые данные для приоритизации.

3.3 Как сейчас организуются матчи?

Зачем: Create Match — заглушка, но матчи в системе есть (иначе зачем экран Matches Page). Значит, кто-то создаёт их вручную через Supabase Studio. Это критически важно для понимания текущего workflow.

Варианты:

• Основатель создаёт вручную — значит, основатель — единственная точка отказа. Create Match — абсолютный приоритет.
• Несколько админов с доступом к Supabase — значит, есть "капитаны", но им нужен удобный инструмент вместо SQL-консоли.
• Матчи создаются, но никто не присоединяется — проблема не в создании, а в привлечении игроков.

3.4 Типичный пользователь: возраст, как часто играет, как нашёл Nukl?

Зачем: Определяет тон коммуникации, каналы маркетинга, дизайн-решения. Исследование предполагает мужчин 18-40, но реальность может отличаться.

3.5 Есть ли "капитаны" — люди, которые сами организуют матчи?

Зачем: Стратегия роста строится на модели "организатор-первым" (один организатор = 10-20 игроков). Если капитаны уже есть — это ядро для масштабирования.

4. Технические вопросы

4.1 Планы по расширению стека (state management)?

Зачем: Текущий подход — setState + ValueNotifier + синглтоны — работает для ~30 экранов, но при росте (чат, создание матча, оплата, лидерборды) станет узким местом. Решение нужно принять до начала Create Match.

Варианты:

• "Оставить как есть" — быстрее разработка сейчас, но рефакторинг потом будет дорогим.
• Riverpod — лёгкий переход, хорошая документация, постепенная миграция.
• Bloc — более строгий, лучше для больших команд, но больше boilerplate.

4.2 Почему go_router подключён, но не используется?

Зачем: Мёртвая зависимость увеличивает размер бандла. Это сознательное решение (планировали мигрировать, не успели) или случайность? Если планировали — стоит мигрировать при реализации invite deep links.

4.3 CI/CD: планируется?

Зачем: RICE-скоринг ставит CI/CD на 2-е место (400 баллов). Без CI/CD каждый деплой — ручной, рискованный процесс. При работе в команде становится критическим.

Варианты:

• Codemagic — Flutter-native, простой setup, бесплатный tier.
• GitHub Actions + Fastlane — более гибкий, но сложнее настроить.
• Не планируется — для solo-разработчика на ранней стадии допустимо, но нужно добавить до публичного запуска.

4.4 Тесты: осознанное решение или не дошли руки?

Зачем: Единственный тест — шаблонный counter test. 0% покрытия. Для серверной части (триггеры, RLS) тесты особенно критичны — ошибка в RLS-политике = утечка данных.

4.5 .env в assets — осознанное решение?

Зачем: .env включён в pubspec.yaml как asset (строка 115). Это означает, что Supabase URL и anon key упакованы в бандл приложения. Anon key по дизайну Supabase публичен (защита через RLS), но если в .env есть service_role key или другие секреты — это серьёзная уязвимость.

Варианты:

• "Там только anon key" — приемлемо, но лучше перенести в dart-define.
• "Там другие ключи тоже" — критический security issue, требует немедленного исправления.

4.6 Supabase plan: Free tier или Pro?

Зачем: Free tier имеет лимиты: 500MB database, 1GB storage, 2GB bandwidth, 50K Edge Function invocations/мес. При росте до 500+ MAU эти лимиты будут достигнуты. Pro plan — $25/мес, но снимает основные ограничения.

4.7 Apple/Google developer accounts: уже есть? Приложение в стадии review?

Зачем: Apple Developer — $99/год, Google Play — $25 единоразово. Получение аккаунтов и прохождение review может занять 1-4 недели. Код уже содержит логику для Apple Sign-In compliance. Версия 1.0.0+14 намекает на несколько итераций сборки.

4.8 Сколько разработчиков планируется привлечь?

Зачем: Влияет на архитектурные решения: при 2+ разработчиках нужны CI/CD, code review процесс, branching strategy, CLAUDE.md / README с правилами проекта.

5. Стратегические развилки

5.1 Сначала глубина или ширина?

Вопрос: Один город с идеальным покрытием (50+ матчей/неделю, партнёрства с полями, 500+ MAU) или 5 городов со средним покрытием (10 матчей/неделю, 100 MAU каждый)?

Рекомендация команды исследователей: Глубина. Один город до достижения 300+ MAU и 50+ матчей/мес, затем расширение.

5.2 Pickup или organized?

Вопрос: Фокус только на спонтанных pickup-играх или сразу включать организованные лиги и турниры?

Рекомендация команды исследователей: Pickup first. Система повторяющихся матчей (Phase 2) — мост к организованному спорту. Турниры — не ранее Phase 3.

5.3 Бесплатно или freemium с первого дня?

Вопрос: Запускать 100% бесплатно для набора базы или сразу вводить подписку Nukl Pro?

Рекомендация команды исследователей: Бесплатно первые 6-12 месяцев (до 5K MAU). Затем мягкое введение Pro с "дедушкиными" правами для ранних пользователей.

5.4 Mobile-only или web тоже?

Вопрос: Фокус исключительно на мобильном приложении или параллельно разрабатывать web-версию?

Рекомендация команды исследователей: Mobile-only. Минимальная web landing page для invite links (preview матча + кнопка "Скачать"). Полноценный web — Phase 3.

5.5 Футбол-only или мультиспорт в будущем?

Вопрос: Nukl остаётся футбольным приложением навсегда или расширяется на другие виды спорта?

Рекомендация команды исследователей: Футбол-only как минимум до 50K MAU. Futsal — естественное расширение (уже поддерживается формациями 5x5). Другие виды — отдельное стратегическое решение.

Резюме: Топ-5 самых важных вопросов

Это вопросы, ответы на которые радикально меняют стратегию, roadmap и распределение ресурсов:

1. "Какой первый город и есть ли там уже пользователи?"

Определяет язык запуска, каналы привлечения, партнёрства, юридическую юрисдикцию, и показывает, находимся мы на стадии pre-launch или early traction. Если пользователи уже есть — нужна аналитика немедленно. Если нет — нужен Create Match немедленно.

2. "Бюджет до первого дохода и амбиции (lifestyle vs venture)?"

При бюджете < $50K и lifestyle-модели стратегия кардинально отличается от venture-backed с $300K pre-seed. В первом случае — bootstrapping, один город, органический рост. Во втором — команда, 3 города, субсидированные капитаны, агрессивный маркетинг.

3. "Почему Create Match — заглушка? Что конкретно блокирует?"

Если блокер технический — решается за 2-4 недели. Если бизнесовый (нет партнёрств с полями) — нужен "come as you are" подход (матч на любом поле/дворе без бронирования). Если идеологический (контроль качества матчей) — нужна модерация, а не заглушка. Ответ определяет архитектуру всей функции.

4. "Кто в команде и сколько разработчиков планируется?"

Solo-founder roadmap и командный roadmap — это два совершенно разных документа. Для одного человека Phase 1 растягивается на 6+ месяцев; для команды из 3-4 — укладывается в 3. Также определяет, нужны ли CI/CD, тесты, CLAUDE.md прямо сейчас или можно отложить.

5. "Сначала глубина или ширина?" (один город идеально vs несколько средне)

Этот выбор определяет: бюджет на city seeding ($3-8K на город), количество капитанов, маркетинговую стратегию, и самое главное — когда будет достигнута критическая масса (200-300 MAU в городе), после которой network effects начинают работать самостоятельно.