TutorVest

Uma plataforma de tutoria personalizada para o Grupo GGE, que tirou o acompanhamento de alunos do WhatsApp e de planilhas e o colocou num só lugar, com métricas para medir o impacto de cada tutoria.

Cliente: Grupo GGE · Juntos Educação
Meu papel: Software Engineer: arquitetura, desenvolvimento e funcionalidades
Time: 5 pessoas · gestão, engenharia e UX/UI
Resultado: MVP homologado e aceito pelo cliente

01 / O problema

Como fazer cada tutor atender mais alunos, com mais qualidade?

O GGE queria um módulo de tutoria que conectasse estudantes a tutores experientes na preparação para vestibulares e ENEM. Mas o processo existente era fragmentado: agendamentos no Google Agenda, planos em Google Docs, conversa no WhatsApp e nenhuma métrica de impacto.

3 tutores no programa

12h por semana, por tutor

50% desse tempo só em planejamento

24 alunos por mês, por tutor

Processo de tutoria descentralizado, em WhatsApp e controles manuais
Nenhuma visibilidade centralizada sobre o progresso dos alunos
Ausência de métricas para avaliar o impacto das tutorias
Agendamentos e registros acadêmicos manuais, consumindo o tempo dos tutores

02 / Descoberta

Entender antes de construir.

Antes de qualquer linha de código, o time investigou o problema com o cliente e com quem vive a tutoria todos os dias.

Investigar Matriz CSD, reuniões com o cliente e pesquisa qualitativa com os tutores
Definir Workshop de problem statement e personas: tutor, aluna e gestor pedagógico
Comparar Análise de quatro soluções existentes, nenhuma cobrindo o ciclo completo
Idear Brainstorming 6-3-5, cluster & vote e matriz de impacto por viabilidade

03 / Solução

Uma aplicação web, três perfis de acesso.

Administrador gerencia alunos e tutores e acompanha métricas. Tutor conduz tutorias, acompanha alunos e gerencia materiais. Aluno agenda tutorias, acessa materiais e realiza avaliações.

Dez funcionalidades entregues em duas etapas: gestão de usuários, tutores e alunos; gestão e agenda de tutorias; repositório de documentos; materiais de estudo e avaliativos; acompanhamento de alunos e insights para o administrador.

O escopo negativo foi explícito desde o início: não é EAD, marketplace de tutores, rede social, sistema de pagamentos, app nativo nem videoconferência.

Diagrama da aplicação TutorVest com três perfis de acesso: administrador, aluno e tutor, cada um com suas responsabilidades — Os três perfis de acesso e suas responsabilidades.

04 / Arquitetura

Modular por domínio, pronta para crescer.

Front-end em Next.js conversando com uma API REST em NestJS, persistência em PostgreSQL via TypeORM, arquivos no Amazon S3 e e-mails transacionais via SMTP. O back-end é modularizado por domínio (usuários, tutorias, sessões, pagamentos); o front-end, por perfil de acesso.

Arquitetura da aplicação: usuário acessa o front-end Next.js por HTTPS, que chama a API NestJS via REST; a API persiste no PostgreSQL e integra com AWS S3 e Google SMTP — Arquitetura da aplicação e integrações externas.

Modelagem DDD Linguagem ubíqua, bounded contexts, entidades e value objects.

Arquitetura Clean Architecture Entidades e casos de uso independentes, frameworks na borda.

Design CQRS Comandos de escrita e consultas de leitura com modelos próprios.

Testes TDD Red, green, refactor. Testes de unidade e de integração.

Segurança Auth e RBAC JWT, papéis e permissões aplicados por guards no NestJS.

Princípios SOLID Os cinco princípios de design orientado a objetos.

Especificação Spec-Driven Development Specs antes do código e geração assistida por IA com Claude Code.

Entrega Gitflow e CI/CD GitHub Actions, imagens Docker e registro no Amazon ECR.

Arquitetura em nuvem na AWS: VPC com subnet pública e privada, instâncias EC2 com security groups, bucket S3 e imagens no ECR vindas do GitHub — Infraestrutura na AWS: VPC com subnets pública e privada, EC2, S3 e ECR.

Fluxo Gitflow com branches main, develop e feature, e pipelines de CI/CD com build, lint, testes unitários e de integração e push da imagem para o ECR — Gitflow e CI/CD: cada PR roda build, lint e testes; cada commit na main publica a imagem no ECR.

05 / Trade-offs

Toda arquitetura é feita de escolhas.

O que ganhamos

Modularização por domínio e por perfil, fácil de evoluir
Domínio centrado nas regras de negócio, com DDD
Desenvolvimento orientado a testes
Separação clara entre escrita e leitura, com CQRS
Segregação de acesso por papel, com RBAC

O que aceitamos

Provisionamento limitado pelos créditos de nuvem do projeto
Envio de e-mails limitado às cotas do SMTP gratuito
Pontos únicos de falha, sem redundância de serviços
Infraestrutura não preparada para picos de demanda

06 / Resultado

MVP homologado pelo cliente.

O escopo do MVP foi validado em reuniões de homologação com o gestor pedagógico do GGE, que confirmou formalmente a entrega.

Entrega além do escopo Os e-mails de boas-vindas e de notificação de tutorias estavam no escopo negativo, mas foram entregues ao longo do projeto.

Mudanças de requisito com baixo impacto A arquitetura modular absorveu mudanças ao longo das entregas sem retrabalho estrutural.

Qualidade validada em cinco etapas Regras de negócio e protótipo revisados antes do desenvolvimento; testes unitários e de integração automatizados no CI; testes de aceitação com cenários reais de uso.

Time Cristiane de Holanda, Cristiano Rego Barros, Luciano Pinheiro, Thays Carvalho e Vítor Aquino

Site do projeto

Tem um produto para tirar do papel?

Let's talk Other projects