Product & Design/UX Decisions — Tech Tennis
Documento vivo de decisões de produto e design. Atualizado conforme o projeto evolui. Última atualização: 2026-03-12
Product Vision
Plataforma two-sided para tênis no Brasil:
- B2C (Jogador): Descobrir quadras/clubes, ver disponibilidade, agendar
- B2B (Clube): Gerenciar quadras, horários, professores, cancelamentos
Phase Roadmap
Phase 1: Diretório B2C (ATUAL)
Objetivo: Criar presença online com SEO, coletar dados de tráfego, validar interesse.
| Item | Status |
|---|---|
| Listagem de clubes com mapa | 🔵 Planejado |
| Perfil individual de clube | 🔵 Planejado |
| Páginas por bairro | 🔵 Planejado |
| Form de contato (donos de quadra) | 🔵 Planejado |
| Captura de interesse (jogadores) | 🔵 Planejado |
| SEO + JSON-LD | 🔵 Planejado |
| LGPD (política de privacidade) | 🔵 Planejado |
| Deploy Vercel | 🔵 Planejado |
O que NÃO tem na Phase 1: Auth, booking, admin, pagamentos, WhatsApp API, coach profiles, ratings/reviews.
Phase 2: B2B MVP (Booking)
- Dashboard para clube (gerenciar quadras, horários)
- Auth: phone + Google login, account merge
- Agendamento online para jogadores
- Multi-plan pricing (mensal, trimestral, semestral, anual)
- Dynamic pricing (hora do dia, dia da semana)
Phase 3: Iterate from Feedback
- WhatsApp integration (lembretes, confirmações)
- Cancelamento/reagendamento com regras por clube
- Sistema de créditos (chuva, etc.)
- Coach management (agenda própria, múltiplos clubes)
Feature Decisions Log
| Decisão | Escolha | Rationale | Data |
|---|---|---|---|
| Mapa | Mapbox GL JS | 5x mais free tier que Google (50k vs 10k loads), migration path pra MapLibre (open source) | 2026-03-11 |
| Mapa (original) | Cancelado após pesquisa mostrar custo superior e lock-in | 2026-03-11 | |
| Diretório | Banco de dados (não estático) | Permite filtros, busca, seed data, futuro admin | 2026-03-11 |
| Auth Phase 1 | Nenhuma | Diretório é público. Auth só na Phase 2 | 2026-03-11 |
| Booking Phase 1 | Nenhum | Foco em validar presença e coletar dados primeiro | 2026-03-11 |
| Beach tennis no enum | SIM, incluir | Muitos clubes de tênis em SP têm quadras de beach tennis. Valor pro usuário | 2026-03-11 |
| Modelo de acesso | Exibir (associado/avulso/híbrido) | Info de alto valor para jogadores decidindo onde jogar | 2026-03-11 |
| Form de contato | In-app, salva no Supabase | Sem envio de email por enquanto. Erick confere via Prisma Studio | 2026-03-11 |
| Captura de interesse | Email OU WhatsApp por clube | "Quer saber quando abrir agendamento?" — cria waitlist por clube | 2026-03-11 |
| Idioma | PT-BR only | Mercado brasileiro. Sem i18n framework | 2026-03-11 |
| Imagens | URLs externas / placeholders | Sem upload na Phase 1. Supabase Storage ou S3 na Phase 2 | 2026-03-11 |
UX Philosophy
Princípios de Design
- Mobile-first: Jogador procura quadra no celular. Desktop é secondary
- Dados úteis, não apenas listados: Horários formatados, preço por hora visível, tipo de quadra como badge colorida
- Mapa como first-class citizen: Não é um extra — é um dos dois modos de navegação (lista + mapa)
- PT-BR nativo: Não é tradução do inglês. Escrito como brasileiro fala
- Simplicidade honesta: Melhor ter pouco e polido do que muito e cru
- Sem dark patterns: Sem pop-ups de email agressivos, sem dados coletados sem consentimento
Competitive UX Advantage
| Competidor | UX Problem | Nossa Solução |
|---|---|---|
| LetzPlay | "Interface poluída, lenta, bugada" (2.7★) | Clean, rápido, funcional |
| Agendei Quadras | Genérico, parece template | Tennis-specific, design autoral |
| NaQuadra | Básico, só listagem | Mapa interativo, perfis completos |
| Google Maps | Dados incompletos/genéricos de quadras | Dados curados com info que o Google não tem (tipo de quadra, se é coberta, preço) |
Data Model (Phase 1)
Entidades Principais
Club
├── name, slug, description
├── neighborhood (bairro) ← obrigatório para endereço BR
├── address, cep, city, state, lat/lng
├── phone (E.164), whatsapp (E.164), website
├── accessModel (MEMBERS_ONLY | PAY_PER_PLAY | HYBRID)
├── isPublished, isVerified
├── Courts[]
├── OperatingHours[]
└── Amenities[]
Court
├── name ("Quadra 1")
├── courtType (CLAY | HARD | GRASS | ARTIFICIAL | CARPET | BEACH_TENNIS)
├── surface ("Saibro"), isIndoor, isLit
└── pricePerHourCents (em centavos, evita float)
OperatingHours (normalizado, não JSONB)
├── dayOfWeek (0=Dom...6=Sáb)
├── openTime ("08:00"), closeTime ("22:00")
└── isClosed
ClubAmenity
├── type (PARKING | LOCKER_ROOM | SHOWER | CAFE | PRO_SHOP | COACHING | WIFI | etc.)
└── notes
ContactSubmission
├── name, clubName, email, phone, message
├── consentGivenAt ← LGPD obrigatório
└── createdAt
PlayerInterest
├── email, whatsapp, clubId
├── consentGivenAt ← LGPD obrigatório
└── createdAt
Decisões de Schema
| Decisão | Escolha | Rationale |
|---|---|---|
| OperatingHours | Tabela normalizada | Permite query "aberto agora?" eficientemente. JSONB não dá pra indexar ranges |
| Pricing tiers | JSONB | Estrutura variável por clube, raramente usado em WHERE |
| Lat/Lng | Float (Decimal) | PostGIS é overkill pra 12 clubes. Adicionar PostGIS na Phase 2 |
| Phone | E.164 (+5511987654321) | Padrão internacional, converte pra display e wa.me/ |
| Preço | Centavos (Int) | Evita problemas de float com dinheiro |
| Slug | Auto-gerado com accent stripping | "São Paulo" → "sao-paulo" |
Scope Boundaries (Phase 1)
INCLUÍDO
- Listagem de clubes em grid + mapa Mapbox
- Perfil individual de clube com todos os dados
- Páginas de bairro
- Form de contato para donos de quadra
- Captura de interesse de jogadores
- SEO (JSON-LD TennisComplex, sitemap, OG tags)
- LGPD compliance (consent, privacy policy)
- Seed data com 12+ clubes reais da Zona Oeste SP
- Deploy no Vercel
EXCLUÍDO
- Autenticação / login
- Booking / agendamento
- Dashboard admin
- Pagamentos / Pix
- WhatsApp API (só links wa.me/)
- Coach profiles
- Ratings / reviews / UGC
- Map clustering / geolocation / directions
- i18n / inglês
- Upload de imagens
- Envio de email
Ideas Backlog (Não-planificadas ainda)
/interno — Documentação navegável com MDX
- Ideia: Rota interna (
/interno) que renderiza os.sisyphus/knowledge/*.mdcomo páginas bonitas - Motivação: User quer aprender MDX; ter documentação de decisões como um "mini website" navegável (similar ao que Claude app faz com artifacts)
- Valor: Referência rápida durante desenvolvimento, base para docs públicas futuramente
- Escopo: Renderizar markdowns existentes com navegação, busca simples, visual bonito
- Aprendizado: MDX, dynamic routes de filesystem, rendering de markdown em Next.js
- Quando: Após Phase 1 (diretório B2C) ou como bonus paralelo
Build-in-Public Diary / Blog Auto-gerado
- Ideia: Log automático do processo de construção — como um diário/blog que se auto-escreve
- Motivação: "Build in open" é uma estratégia de marketing poderosa para solo-founders. Mostra o processo, atrai audiência, e serve como portfolio vivo
- Como poderia funcionar:
- Auto-gerar entries a partir de: git commits, session logs, milestones alcançados
- Formato: data + o que foi feito + learnings + screenshots
- Publicável como blog estático (MDX + Next.js) ou feed em redes sociais
- Sinergias:
- Combina com a rota
/interno(MDX infrastructure compartilhada) - Content marketing gratuito — cada post é distribuição
- Atrai outros founders/devs como audiência (networking)
- Portfolio de "AI-assisted development" é narrativa única em 2026
- Combina com a rota
- Quando: Pode começar simples (markdown manual) e automatizar depois
Referências: .sisyphus/drafts/tennis-saas-vision.md, .sisyphus/knowledge/market-analysis.md