PRD -- Product Requirements Document

Pilot Status

Status

Draft

1. Visão Geral

Pilot Status é uma plataforma SaaS para envio e automação de mensagens para usuários finais (atualmente via WhatsApp), usando números da plataforma e/ou números conectados.

O produto permite que empresas enviem notificações automatizadas com controle de templates, versionamento, ambientes separados (teste e produção), rate limiting por plano e observabilidade completa. Analytics de frontend e backend são realizados com Umami.

2. Problema

Empresas que desejam automatizar envios de mensagens via WhatsApp (ex.: atualizações, OTP e campanhas) enfrentam:

• Complexidade técnica de integração
• Falta de controle de versionamento de templates
• Risco de bloqueio por uso indevido
• Baixa visibilidade sobre falhas e status
• Dificuldade de escalar envios com segurança

3. Objetivos do Produto

Objetivos Principais

• Permitir envio simples e seguro de mensagens de utilidade/atualizações
• Oferecer controle de templates com aprovação
• Separar ambiente de teste e produção
• Garantir rate limit por plano
• Fornecer dashboard com métricas operacionais

Objetivos Secundários

• Permitir escalabilidade gradual
• Manter simplicidade no MVP
• Possibilitar evolução futura (retry, DLQ, backup)

4. Público-Alvo

• Startups
• Micro SaaS
• Produtos digitais
• Plataformas que precisam enviar notificações automatizadas

5. Funcionalidades

5.1 Autenticação

• Login via Google
• Login via GitHub

5.2 Dashboard

Exibir:

• Total de mensagens enviadas
• Total de mensagens com falha
• Gráfico de mensagens nos últimos 4 dias
• Gráfico por status:
  • queued
  • sent
  • failed
  • read

5.3 Templates

Lista

• Filtro por nome
• Filtro por status (aprovado, pendente, rejeitado)
• Cards com:
  • Nome
  • Status
  • ID
  • Corpo da mensagem

Criação

• Nome do template
• Corpo da mensagem (JSON estruturado)
• Botão para adicionar variável
• Botão para preview (modal)
• Submissão para aprovação

Versionamento

• Cada alteração gera nova versão
• Cada versão precisa de aprovação admin
• Logs armazenam versão usada

5.4 Envio de Mensagens (API)

Endpoint para:

• Enviar mensagem
• Consultar status
• Consultar logs

Requisitos:

• API Key obrigatória
• Rate limit aplicado conforme plano (ver seção 5.9)
• No plano Gratuito, ambiente test limitado a 10 mensagens/dia

5.5 Logs

Filtro por:

• Número
• Template

Exibir:

• Data e hora
• Destinatário
• Template
• Status

5.6 API Keys

• Criar nova API Key (modal)
• Exibir chave uma única vez
• Listar chaves:
  • Nome
  • Ambiente
  • Data criação
  • Último uso
  • Ações (copiar, excluir, ver logs)

Formato:

• ps_test_xxxxx
• ps_live_xxxxx

5.7 Perfil

• Nome
• Email
• WhatsApp
• Upload de vídeo
• Botão para solicitar produção

Texto explicativo com diretrizes para vídeo.

5.8 Admin

• Lista de usuários
• Aprovação de templates
• Reprovação com mensagem
• Lista de pedidos de produção
• Aprovação para modo produção

5.9 Planos e Preços

Planos

• Gratuito: 300 mensagens por mês, com limitação de 10 mensagens por dia.
• Basic (R$ 29,90/mês): 700 mensagens por mês, sem limitação de mensagens por dia.
• Pro (R$ 99,90/mês): 3000 mensagens por mês, sem limitação de mensagens por dia.

Pacotes (mensagens adicionais)

Pacotes somam mensagens ao limite do plano vigente no período.

• Pacote 1 (R$ 19,90): adiciona 300 mensagens.
• Pacote 2 (R$ 29,90): adiciona 1000 mensagens.

5.10 Pagamentos

• Stripe: pagamento com cartão para assinatura mensal (planos Basic e Pro) e para compra de pacotes.
• Pague Dev: pagamento via Pix para compra de pacotes e pagamento único quando aplicável.

6. Regras de Negócio

• Multi-tenant com isolamento lógico
• Filas FIFO por tenant
• Webhook interno para atualização de status
• Sem exposição de webhook ao cliente
• Rate limit por API Key baseado em plano e pacotes (limites em 5.9)
• Templates precisam de aprovação
• Versões antigas continuam válidas para logs

7. Métricas de Sucesso

Produto

• Número de tenants ativos
• Mensagens enviadas por dia
• Taxa de falha
• Conversão test → live

Negócio

• Receita por tenant
• Receita por plano (Basic, Pro)
• Venda de pacotes (Pacote 1, Pacote 2)
• Crescimento mensal
• Uso médio por plano

8. Fora do Escopo (MVP)

• Retry automático
• Dead Letter Queue
• Rotação de API Key
• Backup automatizado
• Escopo granular de permissões

9. Roadmap Futuro

• Implementar retry com backoff
• Implementar DLQ
• Adicionar rotação de API Key
• Implementar estratégia de backup
• Melhorar controle de permissões
• Dashboard avançado de métricas

10. Conclusão

O Pilot Status será lançado como MVP focado em simplicidade, controle de templates e segurança operacional básica.

A arquitetura permite evolução gradual para um sistema mais robusto sem necessidade de reestruturação completa.

11. Ambiente de Desenvolvimento com Docker

11.1 Perfis de Compose

O projeto utiliza docker-compose.yml com perfis para separar desenvolvimento e produção:

• prod: usa a imagem otimizada de produção (web e worker atuais).
• dev: usa serviços com hot reload (web-dev e worker-dev).

11.2 Subir ambiente de desenvolvimento (hot reload)

Para desenvolver usando Docker (Next.js e worker com hot reload):

docker compose --profile dev up web-dev worker-dev postgres redis

Características:

• web-dev: roda next dev em apps/web com hot reload.
• worker-dev: roda tsx watch em apps/worker com hot reload.
• Código de apps/web, apps/worker e packages é montado via volumes, então alterações locais são refletidas automaticamente nos containers.

11.3 Subir ambiente de produção

Para simular um ambiente mais próximo de produção (buildado):

docker compose --profile prod up web worker postgres redis

Neste modo:

• web: usa next start com build prévio.
• worker: roda a versão compilada em apps/worker/dist.