Sport Tech Club - Product Roadmap

Roadmap estratégico da plataforma SaaS para gestão de arenas de beach sports

Status: Em Desenvolvimento Última Atualização: 2026-01-09 Versão: 1.0

---

Visão Estratégica

Problema que Estamos Resolvendo

Arenas de beach sports enfrentam desafios críticos de gestão:

• Operação Manual: Planilhas, WhatsApp e processos desconectados
• Falta de Controle: Presença real vs. reservas teóricas
• Experiência Fragmentada: Jogadores interagem com múltiplos sistemas
• Baixa Retenção: Sem gamificação ou economia de tokens
• Desperdício de Recursos: Quadras subutilizadas, sem inteligência de alocação

Nossa Solução

Plataforma integrada que une:

1. Gestão Operacional - Arena opera 100% digital
2. Experiência do Jogador - App unificado com gamificação
3. Economia de Tokens - Wallet digital e incentivos
4. Inteligência de Dados - Insights e otimização

Estratégia de Go-to-Market

MVP (Fase 1)          Fase 2              Fase 3
   │                    │                    │
   ├─> Core Value       ├─> Expansion        ├─> Differentiation
   │   "Must Have"      │   "Should Have"    │   "Wow Factor"
   │                    │                    │
   └─> 1-3 Arenas       └─> 5-10 Arenas      └─> Scale & Network
       Beta Partners        Early Adopters        Market Leadership

---

Arquitetura de Fases

Princípios de Priorização

1. Value First: Resolver dores agudas antes de features "legais"
2. No Workarounds: Se não dá para operar sem, é MVP
3. Technical Foundation: Infraestrutura antes de features complexas
4. Dependencies First: Módulos base antes de módulos derivados
5. Learn Fast: Validar hipóteses críticas cedo

Mapa de Dependências

┌─────────────────────────────────────────────────────────────────┐
│                          FASE 1 - MVP                            │
│  Identity & Access → Arena Mgmt → Courts & Allocation            │
│         ↓                              ↓                         │
│    Scheduling ←────────────────────────┤                         │
│         ↓                              ↓                         │
│  Access & Presence              Play & Match                     │
│         ↓                              ↓                         │
│  Lessons & Coaching             Events (Basic)                   │
│         ↓                              ↓                         │
│         └──────────→ Integration Layer ←─────────┘               │
└─────────────────────────────────────────────────────────────────┘
                             ↓
┌─────────────────────────────────────────────────────────────────┐
│                         FASE 2 - EXPANSION                       │
│  Commerce & Billing → Wallet & Value → Gamification              │
│         ↓                   ↓                ↓                   │
│  Media & Video       Communications    Events (Full)             │
│         ↓                   ↓                ↓                   │
│         └───────→ Scheduling (Advanced) ←────┘                   │
│                           ↓                                      │
│                   Analytics (Basic)                              │
└─────────────────────────────────────────────────────────────────┘
                             ↓
┌─────────────────────────────────────────────────────────────────┐
│                    FASE 3 - DIFFERENTIATION                      │
│  Wallet (Advanced) → Gamification (Advanced) → Sponsorship       │
│         ↓                   ↓                        ↓           │
│  IoT (Advanced)      Intelligence         Performance            │
│         ↓                   ↓                        ↓           │
│         └────────→ Integrations (Expanded) ←─────────┘           │
└─────────────────────────────────────────────────────────────────┘

---

FASE 1: MVP - Core Value

Objetivo: Arena pode operar 100% na plataforma, eliminando planilhas e WhatsApp

Visão Geral

A Fase 1 entrega o mínimo necessário para que uma arena de beach sports opere digitalmente do início ao fim:

• Gestão de quadras em tempo real
• Agendamento e reservas
• Controle de presença física
• Aulas e eventos básicos
• Integração com sistema de acesso (Ziggy)

Critério de Sucesso: Uma arena beta consegue operar 1 semana inteira sem usar planilhas ou WhatsApp.

Módulos MVP

1. Identity & Access Management (IAM)

Por que no MVP: Base técnica para tudo. Sem IAM, nada mais funciona.

Funcionalidades:

• Multi-tenancy (isolamento por arena)
• Usuários e perfis
  • Admin Arena
  • Staff (recepção, quadra)
  • Professor
  • Jogador
• Autenticação (email/senha)
• Login básico
• Gestão de permissões por papel

Dependências: Nenhuma

Entregáveis:

• [ ] Modelo de dados multi-tenant
• [ ] API de autenticação
• [ ] Tela de login (web + app)
• [ ] Gestão de usuários (admin)

---

2. Arena Management

Por que no MVP: Configuração inicial da arena. Sem isso, não há contexto operacional.

Funcionalidades:

• Cadastro de arena
  • Nome, endereço, contato
  • Horários de funcionamento
  • Políticas gerais
• Cadastro de quadras
  • Nome, tipo de esporte
  • Dimensões, características
  • Status (ativa/manutenção)
• Configuração operacional
  • Duração padrão de partidas
  • Tamanho de times
  • Regras de casa

Dependências: IAM

Entregáveis:

• [ ] CRUD de arenas
• [ ] CRUD de quadras
• [ ] Painel de configurações
• [ ] API de contexto (retorna config da arena)

---

3. Courts & Allocation (Core)

Por que no MVP: Coração do sistema. Quadra como entidade inteligente que gerencia estado e alocação.

Funcionalidades:

• Quadra como Entidade Inteligente
  • Estado em tempo real (livre, ocupada, reservada, manutenção)
  • Histórico de estados
  • Perfil de quadra (nível recomendado, gênero)
• Alocação Inteligente
  • Regras básicas de alocação
    • Por nível de jogador
    • Por gênero (se aplicável)
    • Por horário de chegada
  • Fila por quadra
  • Fila global da arena
• Gestão de Fila
  • Entrada manual (staff) ou automática (check-in)
  • Ordem: FIFO + peso por nível
  • Alocação automática quando quadra libera

Dependências: Arena Management

Entregáveis:

• [ ] Modelo de estado de quadra (state machine)
• [ ] Engine de alocação
• [ ] API de fila (adicionar, remover, reordenar)
• [ ] Dashboard de quadras em tempo real
• [ ] Painel de fila (TV/tablet na recepção)

---

4. Scheduling

Por que no MVP: Reservas são críticas para receita e planejamento operacional.

Funcionalidades:

• Agenda Unificada
  • Visualização por quadra
  • Visualização por dia/semana
  • Filtros (tipo de reserva, professor, evento)
• Tipos de Reserva
  • Dedicada (hora marcada, quadra exclusiva)
  • Avulsa (chegou e joga)
  • Aula (bloqueio para professor)
  • Evento (bloqueio especial)
• Políticas
  • Cancelamento (prazos e penalidades)
  • No-show (marcação e consequências)
  • Limites de reservas por usuário

Dependências: Courts & Allocation

Entregáveis:

• [ ] CRUD de reservas
• [ ] Calendário visual (staff)
• [ ] Reserva pelo app (jogador)
• [ ] Notificações de confirmação
• [ ] Sistema de cancelamento

---

5. Access & Presence

Por que no MVP: Diferencial crítico. Saber quem está REALMENTE presente vs. quem apenas reservou.

Funcionalidades:

• Check-in por Quadra
  • Tablet na quadra ou QR code
  • Associa jogador → quadra → horário
• Presença Real
  • Marca presença física
  • Atualiza estado da quadra
  • Alimenta sistema de alocação
• Auditoria Básica
  • Log de entrada/saída
  • Relatório de presença vs. reserva

Dependências: Courts & Allocation, Scheduling

Entregáveis:

• [ ] Interface de check-in (tablet/QR)
• [ ] API de presença
• [ ] Log de auditoria
• [ ] Integração com Ziggy (catraca)

---

6. Lessons & Coaching

Por que no MVP: Aulas são fonte importante de receita e requerem controle especial.

Funcionalidades:

• Cadastro de Professores
  • Perfil, especialidades
  • Disponibilidade
  • Vínculo com arena
• Aulas e Turmas
  • Criação de aula (recorrente ou única)
  • Matrícula de alunos
  • Bloqueio de quadra
• Presença em Aulas
  • Lista de chamada
  • Marcação de falta
  • Relatório de frequência

Dependências: Scheduling, Access & Presence

Entregáveis:

• [ ] CRUD de professores
• [ ] CRUD de aulas/turmas
• [ ] Sistema de matrícula
• [ ] Lista de presença (tablet)

---

7. Play & Match

Por que no MVP: Rastrear partidas é essencial para gamificação futura e histórico.

Funcionalidades:

• Criação de Partidas
  • Manual (staff cria) ou automática (após alocação)
  • Associa quadra + horário
• Times e Jogadores
  • Formação de times
  • Associação de jogadores presentes
• Placar Básico
  • Registro de resultado
  • Vitória/derrota
  • Histórico de partidas

Dependências: Courts & Allocation, Access & Presence

Entregáveis:

• [ ] CRUD de partidas
• [ ] Interface de formação de times
• [ ] Tela de placar (tablet na quadra)
• [ ] Histórico de jogos

---

8. Events (Básico)

Por que no MVP: Arenas fazem eventos frequentemente (torneios, festas). Precisa de modo especial.

Funcionalidades:

• Modo Evento Simples
  • Bloqueia quadras
  • Nome, data, descrição
• Participantes
  • Lista de inscritos
  • Check-in no evento

Dependências: Scheduling

Entregáveis:

• [ ] CRUD de eventos
• [ ] Bloqueio de quadras para evento
• [ ] Lista de participantes
• [ ] Check-in de evento

---

9. Integration Layer

Por que no MVP: Arena usa sistema de catraca (Ziggy). Precisa integrar para check-in automático.

Funcionalidades:

• Adapter para Ziggy
  • Recebe evento de passagem na catraca
  • Identifica usuário (cartão RFID → user ID)
  • Marca presença automaticamente
  • Integra com consumo (se aplicável)

Dependências: Access & Presence

Entregáveis:

• [ ] Adapter Ziggy (webhook ou API)
• [ ] Mapeamento cartão RFID → user
• [ ] Log de integrações

---

Critérios de Sucesso - MVP

Critérios Técnicos:

• [ ] Sistema suporta 3 arenas simultâneas (isolamento multi-tenant)
• [ ] Check-in funciona via tablet e catraca
• [ ] Engine de alocação processa fila em < 2s
• [ ] Uptime > 99% em horário de pico

Critérios de Produto:

• [ ] Arena beta opera 1 semana sem planilhas
• [ ] 100% das presenças registradas digitalmente
• [ ] 0 conflitos de alocação de quadra
• [ ] Staff usa sistema sem treinamento adicional após onboarding

Critérios de Negócio:

• [ ] 3 arenas beta usando em produção
• [ ] NPS > 50 entre staff
• [ ] Tempo de setup de nova arena < 2h
• [ ] Identificados pelo menos 5 insights acionáveis de uso

---

Riscos e Mitigações - MVP

Risco	Probabilidade	Impacto	Mitigação
Integração com Ziggy não funciona como esperado	Média	Alto	Fazer POC de integração antes de MVP completo
Engine de alocação não escala	Baixa	Médio	Testes de carga com 100+ jogadores em fila
Staff resiste a adotar sistema	Média	Alto	Onboarding presencial + suporte 24/7 na primeira semana
Quadras não reportam estado corretamente	Média	Alto	Interface de correção manual + auditoria automática
Multi-tenancy vaza dados entre arenas	Baixa	Crítico	Auditoria de segurança antes de prod + testes de isolamento

---

FASE 2: Expansion

Objetivo: Monetização, engajamento e features que arenas "querem muito"

Visão Geral

A Fase 2 adiciona funcionalidades que:

• Geram receita (Commerce, Billing)
• Aumentam retenção (Wallet, Gamification)
• Melhoram experiência (Media, Communications)
• Expandem capacidades (Events completo, Scheduling avançado)
• Dão visibilidade (Analytics)

Critério de Sucesso: Arenas geram receita pelo sistema e jogadores retornam por gamificação.

Módulos Fase 2

1. Commerce & Billing

Por que na Fase 2: Receita é importante, mas operação vem primeiro. Arenas podem cobrar manualmente no MVP.

Funcionalidades:

• Mensalidades
  • Planos (ilimitado, X vezes/semana)
  • Cobrança recorrente
  • Gestão de inadimplência
• Pacotes
  • Pacote de créditos (10 jogos, 20 jogos)
  • Validade e consumo
• Consumo Integrado
  • Check-in consome crédito
  • Integração com Ziggy (bar, aluguel)
• Pagamentos
  • Gateway (Stripe/MercadoPago)
  • Métodos (cartão, PIX, boleto)
  • Histórico de transações

Dependências: Access & Presence, Integration Layer

Entregáveis:

• [ ] CRUD de planos e pacotes
• [ ] Sistema de cobrança recorrente
• [ ] Integração com gateway de pagamento
• [ ] Painel financeiro (arena)
• [ ] Extrato (jogador)

---

2. Wallet & Value (Core Differentiation)

Por que na Fase 2: Diferencial competitivo, mas requer Commerce funcionando.

Funcionalidades:

• Wallets Digitais
  • Wallet por usuário
  • Wallet da arena (pool de incentivos)
• ArenaToken
  • Token próprio da arena
  • Emissão controlada
  • Conversão Real → Token (taxa definida pela arena)
• Transações Básicas
  • Transferências entre wallets
  • Histórico de transações
  • Saldo em tempo real
• Recompensas
  • Bônus por presença (check-in diário)
  • Bônus por vitórias
  • Resgate de tokens (desconto em mensalidade, produtos)

Dependências: Commerce & Billing

Entregáveis:

• [ ] Sistema de wallet (blockchain-inspired, off-chain)
• [ ] CRUD de ArenaToken
• [ ] Engine de recompensas
• [ ] Interface de wallet (app)
• [ ] Sistema de resgate

---

3. Gamification (Básico)

Por que na Fase 2: Retenção é crítica, mas precisa de histórico de partidas (MVP).

Funcionalidades:

• Rankings
  • Ranking por arena
  • Ranking por quadra/nível
  • Período (mensal, semanal, all-time)
• Badges Básicos
  • Presença (10 jogos, 50 jogos, 100 jogos)
  • Vitórias (primeira, 10, 50)
  • Streaks (5 dias seguidos)
• Histórico de Jogos
  • Feed de partidas
  • Estatísticas pessoais (W/L ratio)
  • Evolução ao longo do tempo

Dependências: Play & Match, Wallet & Value

Entregáveis:

• [ ] Sistema de rankings
• [ ] Engine de badges
• [ ] Feed de atividades
• [ ] Perfil de jogador com stats

---

4. Media & Video

Por que na Fase 2: Features "wow" que arenas pedem, mas não são bloqueantes.

Funcionalidades:

• Integração com Sistema de Vídeo
  • Adapter para sistema de câmeras da quadra
  • Associação vídeo → partida
• Botão de Highlight
  • Staff/jogador marca momento (ponto épico)
  • Gera clipe de 15s antes e depois
• Associação Vídeo-Jogador
  • Tag de jogadores em vídeos
  • Biblioteca pessoal de melhores momentos

Dependências: Play & Match

Entregáveis:

• [ ] Adapter para sistema de vídeo
• [ ] API de marcação de highlight
• [ ] Biblioteca de vídeos (app)
• [ ] Compartilhamento social

---

5. Communications

Por que na Fase 2: Notificações melhoram experiência, mas arena pode avisar manualmente no MVP.

Funcionalidades:

• Push Notifications
  • Chegou sua vez na fila
  • Reserva confirmada
  • Aula amanhã
• E-mail
  • Confirmações
  • Faturas
  • Newsletters
• Avisos
  • Avisos da arena (chuva, manutenção)
  • Avisos do sistema (novidades)

Dependências: Scheduling, Access & Presence

Entregáveis:

• [ ] Serviço de notificações
• [ ] Templates de mensagens
• [ ] Painel de comunicação (arena)
• [ ] Preferências (jogador)

---

6. Events (Completo)

Por que na Fase 2: Eventos básicos no MVP. Versão completa requer Commerce e Wallet.

Funcionalidades:

• All-Inclusive
  • Evento com tudo incluso (consumo livre)
  • Créditos de consumo por participante
• Zonas
  • Zonas VIP, área de jogadores, público
  • Controle de acesso por zona
• Consumo por Evento
  • Tracking de consumo
  • Relatório de consumo por participante
  • Cobrança de extras

Dependências: Events (Básico), Commerce & Billing, Wallet & Value

Entregáveis:

• [ ] Sistema de zonas
• [ ] Gestão de all-inclusive
• [ ] Controle de acesso por zona
• [ ] Relatório de evento

---

7. Scheduling (Avançado)

Por que na Fase 2: Regras complexas de alocação. Scheduling básico funciona no MVP.

Funcionalidades:

• Regras Avançadas de Alocação
  • Prioridade por nível de fidelidade
  • Grupos de amigos (alocar juntos)
  • Blacklist de combinações (não alocar A com B)
• Ganha-Fica Completo
  • Time vencedor fica
  • Fila de desafiantes
  • Configurável por quadra
• Waitlist
  • Lista de espera para horários lotados
  • Notificação automática de vaga

Dependências: Scheduling, Courts & Allocation, Gamification

Entregáveis:

• [ ] Engine de alocação avançada
• [ ] Sistema de ganha-fica
• [ ] Waitlist
• [ ] Configuração de regras (admin)

---

8. Analytics (Básico)

Por que na Fase 2: Dados são importantes, mas operação vem primeiro.

Funcionalidades:

• Relatório de Ocupação
  • Taxa de ocupação por quadra
  • Horários de pico
  • Tendências
• Relatório de No-Show
  • Taxa de no-show por usuário
  • Impacto em receita
• Dashboard Executivo
  • Métricas principais (ocupação, receita, usuários ativos)
  • Comparação de períodos

Dependências: Scheduling, Access & Presence, Commerce & Billing

Entregáveis:

• [ ] Data warehouse (básico)
• [ ] Dashboards de ocupação
• [ ] Relatório de no-show
• [ ] Exportação de dados

---

Critérios de Sucesso - Fase 2

Critérios Técnicos:

• [ ] Sistema processa pagamentos com sucesso > 99%
• [ ] Wallet registra transações em < 1s
• [ ] Notificações enviadas em < 5s após evento
• [ ] Analytics atualiza dashboards a cada 5min

Critérios de Produto:

• [ ] Arenas cobram 100% das mensalidades pelo sistema
• [ ] Jogadores usam wallet em 50%+ das transações
• [ ] Ranking visualizado por 70%+ dos jogadores ativos
• [ ] No-show reduz em 30% com notificações

Critérios de Negócio:

• [ ] 10+ arenas usando em produção
• [ ] GMV (Gross Merchandise Value) > R$ 50k/mês
• [ ] Churn de jogadores < 20%/mês
• [ ] NPS > 60

---

Riscos e Mitigações - Fase 2

Risco	Probabilidade	Impacto	Mitigação
Gateway de pagamento tem downtime	Média	Alto	Fallback para 2+ gateways + fila de retry
Jogadores não entendem sistema de wallet	Alta	Médio	Onboarding gamificado + tutoriais in-app
Vídeos consomem muito storage	Alta	Médio	Integração com Cloudflare Stream + política de retenção
Notificações consideradas spam	Média	Médio	Preferências granulares + rate limiting
Analytics muito lento	Baixa	Médio	Pipeline assíncrono + cache agressivo

---

FASE 3: Differentiation

Objetivo: Inovação, network effects e features que nenhum concorrente tem

Visão Geral

A Fase 3 transforma o Sport Tech Club em uma plataforma, não apenas um software:

• Economia de tokens avançada (apostas, "valendo")
• Gamificação social e competitiva
• Patrocínios e receita adicional
• IoT e automação
• Inteligência preditiva
• Integração com ecossistema externo

Critério de Sucesso: Sport Tech Club é visto como a plataforma mais inovadora do setor.

Módulos Fase 3

1. Wallet & Value (Avançado)

Por que na Fase 3: Funcionalidades de alto risco que requerem base sólida de usuários.

Funcionalidades:

• Apostas entre Times
  • Times apostam ArenaToken na partida
  • Vencedor leva o pool
  • Comissão para arena (5-10%)
• Partidas "Valendo"
  • Jogador aposta tokens individuais
  • Partidas com stake alto aparecem em destaque
• Conversões
  • Token → Real (cashout com taxa)
  • Token Arena A → Token Arena B (network)
• Integração Antóctica
  • Antóctica como camada de liquidez
  • Conversão para stablecoins
  • Transferência entre arenas via blockchain

Dependências: Wallet & Value (Básico), Play & Match

Entregáveis:

• [ ] Sistema de apostas (compliance e legal)
• [ ] Engine de partidas "valendo"
• [ ] Conversão Token ↔ Real
• [ ] Integração blockchain (Antóctica)

---

2. Gamification (Avançado)

Por que na Fase 3: Features complexas que requerem massa crítica de usuários.

Funcionalidades:

• Campeonatos Completos
  • Criação de campeonatos (arena ou comunidade)
  • Fase de grupos + mata-mata
  • Premiação em tokens
  • Transmissão ao vivo
• Desafios
  • Jogador desafia outro
  • Aceite/recusa
  • Partida agendada
• XP e Níveis
  • Sistema de experiência (check-ins, vitórias, streaks)
  • Níveis (Iniciante → Lenda)
  • Benefícios por nível (prioridade, descontos)
• Social Features
  • Feed social (mural)
  • Comentários em partidas
  • Amigos e rivalidades

Dependências: Gamification (Básico), Wallet & Value (Avançado)

Entregáveis:

• [ ] Sistema de campeonatos
• [ ] Engine de desafios
• [ ] Sistema de XP e níveis
• [ ] Feed social

---

3. Sponsorship & Ads

Por que na Fase 3: Receita adicional, mas requer audiência significativa.

Funcionalidades:

• Patrocinadores
  • Cadastro de marcas
  • Pacotes de patrocínio
  • Logo em uniformes virtuais
• Inventário de Anúncios
  • Banners em app/web
  • Anúncios em vídeos de highlight
  • Espaço de branding na quadra (virtual overlay)
• Métricas de Exposição
  • Impressões
  • Tempo de exposição
  • Conversões (cupons, links)

Dependências: Media & Video, Analytics (Básico)

Entregáveis:

• [ ] CRUD de patrocinadores
• [ ] Ad server (inventário)
• [ ] Sistema de métricas
• [ ] Dashboard de patrocinador

---

4. IoT (Avançado)

Por que na Fase 3: Hardware é complexo e caro. Apenas em arenas premium.

Funcionalidades:

• Sensores
  • Sensores de presença em quadra
  • Sensores de bola (velocidade, trajetória)
  • Condições ambientais (temperatura, vento)
• Wearables
  • Pulseiras de atleta (frequência cardíaca, calorias)
  • Integração com Apple Watch/Garmin
• Automações
  • Iluminação automática (quadra ocupada = luz ligada)
  • Som ambiente por quadra
  • Placar eletrônico atualizado automaticamente

Dependências: Courts & Allocation, Play & Match

Entregáveis:

• [ ] Adapter para sensores IoT
• [ ] Integração com wearables
• [ ] Sistema de automação
• [ ] Dashboard de dispositivos

---

5. Intelligence

Por que na Fase 3: IA/ML requer volume grande de dados históricos.

Funcionalidades:

• Previsão de Demanda
  • ML prevê ocupação futura
  • Recomendação de horários promocionais
• Recomendações
  • Sugere jogadores para formar times balanceados
  • Sugere desafios (skill matching)
• Pricing Dinâmico (Futuro)
  • Preço varia por demanda
  • Horários nobres mais caros

Dependências: Analytics (Básico), Scheduling (Avançado)

Entregáveis:

• [ ] Modelo de previsão de demanda
• [ ] Sistema de recomendações
• [ ] Engine de pricing dinâmico (futuro)
• [ ] Dashboard de insights

---

6. Performance & Evolution

Por que na Fase 3: Analytics avançados requerem dados ricos e histórico longo.

Funcionalidades:

• Estatísticas Avançadas
  • Pontos por set, aces, erros
  • Heatmap de posição em quadra
  • Comparação com média da arena
• Evolução de Jogador
  • Gráficos de evolução (W/L, nível)
  • Identificação de pontos fortes/fracos
• Coaching Insights
  • Relatórios para professores
  • Análise de aluno (frequência, evolução)
  • Sugestões de treino

Dependências: Play & Match, Lessons & Coaching, IoT (se aplicável)

Entregáveis:

• [ ] Estatísticas avançadas
• [ ] Dashboard de evolução
• [ ] Relatórios de coaching
• [ ] API de dados para coaches

---

7. Integrations (Expandido)

Por que na Fase 3: Integrações de nicho, úteis para arenas específicas.

Funcionalidades:

• CRM
  • Integração com HubSpot, Salesforce
  • Sincronização de contatos
  • Campanhas de marketing
• ERP
  • Integração com ERPs locais
  • Sincronização de receitas
  • Relatórios fiscais
• Marketplaces
  • Integração com iFood (delivery de arena)
  • Integração com ClassPass (descoberta)
  • Integração com Sympla (eventos)

Dependências: Commerce & Billing, Events (Completo)

Entregáveis:

• [ ] Adapters para CRMs
• [ ] Adapters para ERPs
• [ ] Adapters para marketplaces
• [ ] Marketplace de integrações (community)

---

Critérios de Sucesso - Fase 3

Critérios Técnicos:

• [ ] Sistema suporta 100+ arenas simultâneas
• [ ] Latência de API < 100ms (p95)
• [ ] Modelo de ML atinge 80%+ acurácia em previsões
• [ ] Blockchain transactions < 10s

Critérios de Produto:

• [ ] Apostas movimentam > 10k tokens/dia
• [ ] Campeonatos com 50+ participantes regulares
• [ ] Patrocinadores geram 10%+ da receita total
• [ ] IoT deployado em 20%+ das arenas

Critérios de Negócio:

• [ ] 50+ arenas usando em produção
• [ ] GMV > R$ 500k/mês
• [ ] Network effect: jogadores transitam entre arenas
• [ ] Receita de patrocínios > R$ 50k/mês
• [ ] NPS > 70

---

Riscos e Mitigações - Fase 3

Risco	Probabilidade	Impacto	Mitigação
Regulamentação proíbe apostas em esportes amadores	Média	Crítico	Parecer jurídico antes de desenvolver + pivot para "desafios simbólicos"
Blockchain transaction fees inviabilizam micro-transações	Alta	Alto	Layer 2 ou solução off-chain com settlements periódicos
IoT hardware muito caro para arenas	Alta	Médio	Modelo de leasing + prova de ROI
IA faz previsões ruins e prejudica negócio	Média	Alto	Modo "sugestão" (não automático) + override manual
Patrocinadores não veem valor	Média	Médio	POC com 1-2 marcas antes de build completo

---

Matriz de Priorização

Por Valor vs. Esforço

┌─────────────────────────────────────────────────────────────────┐
│                                                                  │
│   Alto Valor       │  QUICK WINS              │  BIG BETS       │
│                    │  - Courts & Allocation   │  - Wallet       │
│                    │  - Access & Presence     │  - Gamification │
│                    │  - Scheduling            │  - Commerce     │
│   ────────────────────────────────────────────────────────────  │
│                    │  LOW PRIORITY            │  HARD SLOG      │
│   Baixo Valor      │  - Integrações de nicho  │  - IoT          │
│                    │  - Features "vanity"     │  - Intelligence │
│                    │                                             │
│                        Baixo Esforço ──────> Alto Esforço       │
└─────────────────────────────────────────────────────────────────┘

Por Impacto no Negócio

Feature	Adoção	Retenção	Receita	Diferenciação	Total	Fase
Courts & Allocation	★★★★★	★★★★★	★★★☆☆	★★★★★	22	1
Wallet & Value	★★★★☆	★★★★★	★★★★☆	★★★★★	21	2
Commerce & Billing	★★★★★	★★★☆☆	★★★★★	★★★☆☆	19	2
Gamification	★★★★☆	★★★★★	★★★☆☆	★★★★☆	19	2
Access & Presence	★★★★★	★★★★☆	★★★☆☆	★★★★★	20	1
Scheduling	★★★★★	★★★★☆	★★★★☆	★★★☆☆	18	1
Intelligence	★★★☆☆	★★★☆☆	★★★★☆	★★★★★	17	3
Sponsorship	★★★☆☆	★★☆☆☆	★★★★★	★★★★☆	16	3
IoT	★★☆☆☆	★★★☆☆	★★☆☆☆	★★★★★	14	3

---

Dependências Técnicas Críticas

Infraestrutura Necessária

Fase 1 (MVP)

Serviços:
  - PostgreSQL (multi-tenant via schemas)
  - Redis (cache, state machine)
  - API Gateway (rate limiting, auth)
  - Object Storage (S3/Minio para arquivos)

Integrações:
  - Ziggy (webhook/API para catraca)

Monitoramento:
  - Logs centralizados
  - APM básico
  - Alertas de downtime

Fase 2 (Expansion)

Serviços (adicionais):
  - Message Queue (RabbitMQ/SQS para async jobs)
  - Push Notification Service (FCM/APNS)
  - Email Service (SendGrid/AWS SES)
  - Payment Gateway (Stripe/MercadoPago SDK)
  - Data Warehouse (BigQuery/Redshift para analytics)

Integrações:
  - Gateway de pagamento
  - Sistema de vídeo (via API ou webhook)

Monitoramento:
  - Dashboard de métricas de negócio
  - Alertas de transações falhadas

Fase 3 (Differentiation)

Serviços (adicionais):
  - ML Platform (TensorFlow Serving ou SageMaker)
  - Blockchain Node (Antóctica)
  - IoT Platform (AWS IoT Core ou similar)
  - Ad Server
  - CDN para vídeos (Cloudflare Stream)

Integrações:
  - CRMs (HubSpot, Salesforce)
  - ERPs (diversos)
  - Marketplaces (iFood, ClassPass, Sympla)
  - Wearables (Apple HealthKit, Google Fit)

Monitoramento:
  - ML model performance
  - Blockchain transaction tracking
  - IoT device health

---

Estratégia de Rollout

Arenas Beta (MVP)

Perfil Ideal:

• Arena estabelecida (1+ ano de operação)
• 50-200 jogadores ativos
• Staff tech-savvy
• Localização próxima (suporte presencial)
• Disposição a dar feedback

Processo de Onboarding:

1. Semana 1: Setup + treinamento staff
2. Semana 2-3: Operação paralela (sistema + planilhas)
3. Semana 4: 100% sistema
4. Semana 5+: Coleta de feedback e iteração

Expectativa: 3 arenas beta operando com sucesso antes de Fase 2.

---

Early Adopters (Fase 2)

Perfil Ideal:

• Arenas que souberam do produto via boca-a-boca
• Já vêm com expectativa de pagar
• Diversidade de tamanho (pequena, média, grande)

Processo:

1. Self-service onboarding (reduzir custo de aquisição)
2. Suporte remoto (base de conhecimento + chat)
3. Upsell de features premium (Media, Analytics)

Expectativa: 5-10 arenas pagantes na Fase 2.

---

Scale (Fase 3)

Perfil: Qualquer arena interessada.

Processo:

1. Marketing outbound (vendas ativas)
2. Freemium model (grátis para pequenas arenas)
3. Marketplace de integrações (community-driven)
4. Programas de incentivo (indicação de arena ganha créditos)

Expectativa: 50+ arenas na Fase 3.

---

Métricas de Sucesso por Fase

Métricas North Star

Fase	North Star Metric	Por quê
MVP	% de tempo que arena opera sem planilhas	Valida que substituímos workflow antigo
Fase 2	GMV (Gross Merchandise Value)	Valida que geramos receita
Fase 3	Network effects (jogadores que jogam em 2+ arenas)	Valida que somos plataforma, não ferramenta

Métricas Secundárias

MVP

• Arenas ativas semanalmente
• Check-ins por arena/dia
• Taxa de adoção do staff (% usando sistema)
• Tempo de setup de nova arena

Fase 2

• ARR (Annual Recurring Revenue)
• Churn de arenas
• Transações em wallet/dia
• NPS (jogadores e staff)

Fase 3

• Arenas na plataforma
• Cross-arena engagement
• Receita de patrocínios
• Receita de integrações (marketplace)

---

Cadência de Releases

Modelo de Release

MVP (Fase 1):
  └─> Releases semanais (sprints de 2 semanas, deploy na sexta da sprint par)

Fase 2:
  └─> Releases contínuas (CI/CD, feature flags)

Fase 3:
  └─> Releases diárias (trunk-based development)

Feature Flags

Todas as features de Fase 2 e 3 devem ser desenvolvidas atrás de feature flags, permitindo:

• Rollout gradual (10% → 50% → 100% das arenas)
• A/B testing (testar duas versões de uma feature)
• Kill switch (desligar feature com problema instantaneamente)

---

Comunicação do Roadmap

Audiências

Audiência	O que comunicar	Como	Frequência
Clientes (Arenas)	Próximos lançamentos, benefícios	Newsletter, in-app, roadmap público	Mensal
Jogadores	Novas features, gamificação	Push, feed social	Por release
Investidores	Tração, métricas, visão de longo prazo	Board deck	Trimestral
Time Interno	Prioridades, dependências, bloqueios	All-hands, Slack	Semanal
Comunidade Open Source	Issues, RFCs, contribuições	GitHub, Discord	Contínuo

Roadmap Público

Manter um roadmap público (estilo GitHub Projects ou Linear Roadmap) com:

• ✅ Shipped: O que já foi entregue
• 🚧 In Progress: O que estamos desenvolvendo agora
• 🔜 Next: Próxima prioridade (próximos 3 meses)
• 🤔 Under Consideration: Investigando viabilidade
• ❄️ Icebox: Boas ideias, mas não agora

---

Feedback Loop

Como Priorizamos Features

1. Dor do Cliente (mais importante)

   • Feature resolve problema crítico?
   • Quantas arenas/jogadores afetados?
   • Impacto em churn?

2. Alinhamento Estratégico

   • Feature está no roadmap?
   • Alinha com visão de longo prazo?

3. Esforço vs. Valor

   • ROI esperado?
   • Tempo de desenvolvimento?
   • Risco técnico?

4. Aprendizado

   • Feature valida hipótese importante?
   • Gera dados para decisões futuras?

Canais de Feedback

• In-app feedback widget (Canny, UserVoice)
• Customer Success calls (mensal com cada arena)
• NPS surveys (trimestral)
• Feature requests no GitHub (community-driven)
• Discord/Slack community (real-time)

---

Considerações Finais

Princípios Imutáveis

Independente da fase, sempre:

• ✅ Simplicidade > Complexidade
• ✅ Feedback rápido > Planejamento perfeito
• ✅ Dados > Opiniões
• ✅ Clientes > Roadmap

O que Não Fazer

• ❌ Prometer datas fixas (prometa fases, não datas)
• ❌ Desenvolver sem validar com cliente
• ❌ Adicionar features que não usamos (dogfooding)
• ❌ Otimizar prematuramente (scale when it hurts)

Revisão do Roadmap

Este roadmap é um documento vivo. Revisamos:

• Semanalmente: Prioridades da sprint
• Mensalmente: Progresso da fase
• Trimestralmente: Visão estratégica de longo prazo

Última revisão: 2026-01-09 Próxima revisão planejada: 2026-04-09

---

Referências

• Product Roadmap - Lenny's Newsletter
• Escaping the Build Trap - Melissa Perri
• Inspired - Marty Cagan
• Shape Up - Basecamp

---

"Build something people want." — Paul Graham, Y Combinator

"Make something people love, not something people like." — Brian Chesky, Airbnb

"If you're not embarrassed by the first version of your product, you've launched too late." — Reid Hoffman, LinkedIn