Frila · Escopo do MVP

Versão 1.0 · 22 de setembro de 2026

O que entra em cada versão do Frila, o que fica fora e por quê, e como o trabalho se divide em sprints até a loja. Este documento é a fonte do quadro do Trello (https://trello.com/b/0eyqvbRJ/frila) e tem uma cópia editável em https://claude.ai/code/artifact/7c7cc595-0666-4687-a586-316e542f7d70.

Resumo

O MVP do Frila é um app iOS, só no Distrito Federal, que fecha o ciclo de um turno avulso de ponta a ponta: o contratante publica a vaga com poucos campos, os profissionais perto recebem a notificação e se candidatam sem formulário, o primeiro aceito é confirmado, faz check-in no local e os dois se avaliam com Sim ou Não.

Ele vai para a App Store em 13/11/2026 (v1.0). Antes disso, o protótipo clicável é apresentado na Apple Review de 28/09 (v0.1) e um TestFlight interno fecha o ciclo em 27/10 (v0.5). Entram as 19 histórias MUST do Backlog v1.2.0, menos a parte web do Painel do gestor. Ficam para a v1.1 (dezembro) o modo seleção, a equipe de confiança e o suporte por e-mail, e para a v1.2 (1º trimestre de 2027) o Android, a web com o Painel e a escala de evento em lote.

O time tem três desenvolvedores (Cauê, João Paulo e Matheus), uma PO (Júlia) e um designer (Fabrício), e sete semanas até a loja.

Critério de corte

Entra na v1.0 o que é preciso para um turno acontecer de ponta a ponta no iOS, no DF, e o que a App Store exige para aprovar o app. Cada história do Backlog passou por quatro perguntas, nesta ordem:

1. Sem isso o ciclo não fecha? Publicar, notificar, candidatar, confirmar, liberar contato, fazer check-in e avaliar entram.
2. A App Store exige? Excluir a conta de dentro do app (diretriz 5.1.1(v)), denunciar e bloquear (diretriz 1.2) e a política de privacidade entram.
3. É a tese do produto? Despacho por proximidade sem levas, reputação binária com denominador e valor integral para o profissional entram, porque são o que diferencia o Frila do grupo de WhatsApp.
4. Só faz sentido com volume ou com outra plataforma? Escala em lote, Painel web, Android, relatório consolidado e múltiplos membros ficam para depois.

A base é a prioridade MoSCoW do Backlog v1.2.0: MUST vai para a v1.0, SHOULD para a v1.1 e COULD para a v1.2. A única exceção é a US21: o alerta de vaga vazia e a confirmação de check-in manual entram na v1.0, no app, e o Painel web vai para a v1.2, junto com a versão web. Fora do produto continuam pagamento no app, CLT, chat, nota de 1 a 5, aval externo e operação fora do DF.

O que entra na v1.0 (MVP)

A v1.0 é um app iOS (iOS 17 ou superior), com dois perfis e um perfil por conta, para o Distrito Federal, com o backend no Supabase. São 19 histórias e 90 pontos, todas MUST no Backlog v1.2.0.

Também fazem parte da v1.0, sem história própria: a política de privacidade e os termos de uso publicados, o texto "Por que recebo vagas" no perfil (a explicação, sem o botão Contestar), leitura offline dos turnos confirmados (RNF06), acessibilidade com VoiceOver e Dynamic Type (RNF10) e a telemetria mínima para medir o piloto.

O que fica fora do MVP

Oito histórias do Backlog e três plataformas ficam para depois da loja. Nenhuma delas impede um turno de acontecer no DF pelo iPhone.

Fora do produto, sem data: pagamento dentro do app (RN09), contratação CLT e processo seletivo, chat interno, nota de 1 a 5, aval de fora da plataforma, rede social e operação fora do DF antes da consolidação.

Versões e iterações

A v1.1 só começa depois da loja: até 13/11 toda a capacidade do time vai para a v1.0. O que o piloto mostrar entre 13/11 e 04/12 reordena a v1.1; a lista acima é o ponto de partida, não um compromisso.

Fluxos de uso da v1.0

Dois fluxos, um por perfil, que se encontram na vaga. Cada caixa é uma tela do protótipo clicável.

flowchart LR
  A[Entrar com código no e-mail] --> B[Perfil de contratante]
  B --> C[Cadastrar estabelecimento]
  C --> D[Publicar vaga]
  D --> E{Vaga preenchida?}
  E -- não, a 3 h do início --> F[Alerta de vaga vazia]
  F --> D
  E -- sim --> G[Confirmado e contato]
  G --> H[Confirmar check-in manual]
  H --> I[Avaliar: chamaria de novo?]

O contratante publica e espera: o Frila notifica quem está perto e o avisa se a vaga seguir vazia. Ele só volta a agir para confirmar um check-in manual e para avaliar.

flowchart LR
  A[Entrar com código no e-mail] --> B[Perfil de profissional]
  B --> C[Funções, ponto base e grade]
  C --> D[Notificação de vaga]
  D --> E[Ver vaga e reputação do local]
  E --> F[Candidatar-me]
  F --> G{Primeiro a aceitar?}
  G -- sim --> H[Confirmado: contato liberado]
  G -- não --> I[Vaga já preenchida]
  I --> E
  H --> J[Check-in até 200 m]
  J --> K[Check-out e avaliar]

O profissional recebe, decide e vai. Perder a corrida no modo urgência é normal e a tela diz isso sem culpa; ele volta à lista de vagas do DF.

As 26 histórias completas, com narrativa e cenários BDD, estão na coluna "Histórias de usuário" do quadro do Trello e no Backlog v1.2.0.

Sprints até a loja

Quatro sprints de 22/09 a 13/11. O Sprint 0 é de fundação e termina no marco que o FigJam já marcava (05/10); os outros têm duas semanas, e o último é mais curto porque termina na loja. Cada sprint tem uma pergunta que responde e o backend anda uma etapa à frente do iOS.

Depois da loja, a coluna Backlog v1.1 tem 10 cartões e a v1.2 tem 7. Se o Sprint 2 atrasar, o corte segue esta ordem, sem tocar no ciclo nem no que a App Store exige: republicar vaga (US05), aviso de hora excedida, lembrete de 24 h (fica só o de 3 h) e exportar dados (excluir conta fica). Nunca saem: candidatura e confirmação, check-in, avaliação, denúncia e bloqueio, exclusão de conta.

Riscos e dependências

Dependências externas fora do controle do time: aprovação da Apple, entrega do FCM e da APNs, disponibilidade do Supabase no horário de pico (RNF12) e a agenda dos estabelecimentos do piloto.

O quadro do Trello

O quadro tem 2 cartões de leitura, 26 histórias de usuário e 101 tarefas (84 até a loja, 17 depois). Cada tarefa tem etiquetas, responsável sugerido, história ou requisito, contexto, o que fazer, critérios de aceite e referências.

O nome de cada cartão carrega o sprint e a área (S1 · Backend · …). As etiquetas estão na primeira linha da descrição (#backend #must #epico-4), porque a integração usada para montar o quadro não cria etiquetas coloridas; para tê-las, basta criar no menu do quadro as de área (Backend, iOS, Design, Produto, Pesquisa, Jurídico, Infra, QA) e as de prioridade (MUST, SHOULD, COULD). O prazo de cada cartão é o fim do sprint, salvo os marcos fixos: 28/09, 27/10, 06/11, 10/11 e 13/11.

Responsáveis são sugestão, não atribuição: Cauê no backend e na infra, João Paulo e Matheus no iOS e no backend, Fabrício no design, Júlia em produto, pesquisa e jurídico.

Fontes: Documento de Requisitos v1.3.0, Documento de Visão v1.2.0, Histórias de Usuário e Backlog v1.2.0, contrato da API 0.2.0, notas de arquitetura do vault (Arquitetura, Classe, Banco, Casos de Uso, Pendências Técnicas), quadro 03 do FigJam e as tarefas T-0010 a T-0024. As datas dos marcos vêm do calendário do CBL C18.