PORTFÓLIO / SKALAY MEMBERS · EM CONSTRUÇÃO
E se uma plataforma de cursos deixasse de medir quanto o aluno assistiu e começasse a medir o que ele realmente aprendeu?
O Skalay começou como uma tentativa de construir uma área de membros melhor.
Essa definição durou pouco.
Quando comecei a decompor escolha, abandono, dúvida, progresso, suporte, certificação, atualização de conteúdo e sustentabilidade do produtor, o reprodutor de vídeo virou o que ele sempre foi: apenas a parte visível.
A pergunta mudou. Como transformar uma biblioteca de conteúdo em um sistema que acompanha aprendizagem?

02 / O PONTO DE PARTIDA
Eu não queria construir outro lugar para armazenar vídeos.
Curso. Módulo. Aula. Player. Percentual concluído. Certificado no final.
Essa sequência entrega conteúdo. Mas a experiência real do aluno continua fazendo perguntas que ela não responde.
Estou estudando a coisa certa? Onde estou travando? Quem responde quando surge uma dúvida? O certificado prova o quê? O conteúdo ainda está atualizado?
- Curso
- Módulo
- Aula
- Player
- % concluído
- Certificado
Foi aí que o produto deixou de ser pensado como uma área de membros. A entrega em vídeo continuaria existindo – só deixaria de ser o fim.
03 / ANTES DO CÓDIGO
Eu não comecei construindo telas. Comecei tentando destruir ambiguidades.
Antes de escolher interface, tecnologia ou funcionalidade, o problema foi dividido em oito territórios.
Cada decisão precisava responder duas perguntas: o que estamos tentando resolver e por que isso merece existir?
Ao final do planejamento fundacional, havia 54 decisões estratégicas documentadas.
diagnóstico, trilha e aprendizagem adaptativa
dúvida, comunidade e presença do produtor
marcos, domínio e camadas de autoridade
celular, retomada e independência do reprodutor de vídeo
recorrência, produto avulso e produto de maior valor
versão, atualidade e revisão
dados, retenção e decisão
tenancy, economia, integrações e expansão
Código rápido não compensa uma regra de negócio mal definida.
04 / A PRIMEIRA MUDANÇA DE MÉTRICA
Assistir não é aprender.
É fácil medir consumo. Vídeo reproduzido, minuto assistido, aula aberta, percentual concluído.
O problema é transformar esse número em uma afirmação que ele não consegue sustentar.
O planejamento passou então a tratar progresso como evidência observável – não apenas tempo de tela.
- 57% dos vídeos?
- 57% dos minutos?
- 57% das aulas abertas?
- 01Exercício concluído
- 02Caso analisado
- 03Atividade entregue
- 04Domínio demonstrado
- 05Marco aprovado
A mudança parece semântica até percebermos o que ela altera: trilha, progresso, certificação e até a forma como a IA pode ajudar.
05 / CERTIFICADO NÃO É PROGRESS BAR EM PDF
Chegar ao fim de todos os vídeos não deveria dar à plataforma uma autoridade que ela não tem.
Se o certificado nasce apenas porque alguém chegou a 100%, ele prova presença. Não necessariamente domínio.
Por isso, o desenho separou participação, domínio e certificação institucional – três coisas diferentes, com critérios e autoridades diferentes.
Percurso e critérios mínimos concluídos. Esta camada já faz parte da primeira versão operacional.
Selos ligados a competências ou temas específicos, condicionados a evidência maior que simples consumo.
Avaliação superior com participação humana de uma instituição habilitada ou reconhecida. A autoridade não é autodeclarada pela plataforma.
Nem tudo que pode ser automatizado deveria ter sua autoridade automatizada.
06 / O SEGUNDO PROBLEMA
Uma aula gravada sabe o que o professor disse. Não sabe se o aluno entendeu.
A dúvida pode nascer no minuto 14 de uma aula às 22h de uma quinta-feira.
Até a próxima live, ela pode ter virado bloqueio. Ou desaparecido junto com o aluno.
O planejamento separou a solidão do ensino online em três problemas diferentes.
A dúvida é imediata e contextual. Se ficar sem resposta, o aluno perde o fio.
Aqui o problema é pertencimento e contexto – não um fórum global sem propósito.
A experiência precisa reconhecer quando aplicação prática exige validação humana.
Chamar tudo de “suporte” escondia três necessidades diferentes – e, portanto, três regras diferentes.
07–08 / O TUTOR DE IA
A regra mais importante da IA não é responder. É saber quando não responder.
O tutor foi desenhado para trabalhar dentro do conhecimento autorizado pelo produtor – aula, transcrição, material e fontes aprovadas.
A IA não deveria virar uma autoridade paralela ao professor só porque consegue escrever com fluidez.
Na implementação atual, resposta, recusa e escalada são estados explícitos. A proveniência continua ligada à fonte que sustenta a resposta.

Priorize uma captura em que a resposta mostre contexto e origem da informação, sem expor dados sensíveis.
- CAMINHO
- /images/portfolio/skalay-members/tutor-ia-na-aula.webp
- FORMATO
- WEBP
- TAMANHO
- 1600 × 1000 px
- PROPORÇÃO
- 8:5
Quando existe base suficiente e autorizada para aquela pergunta.
Quando a resposta precisa deixar claro de onde veio a evidência.
Quando falta evidência, existe risco, conflito de fonte ou o caso pede uma pessoa.
Uma resposta segura pode ser menor. Às vezes, a melhor resposta é reconhecer o limite.
09–10 / COMUNIDADE E PRIVACIDADE
Conectar duas pessoas parece uma funcionalidade social. Até aparecer a primeira pergunta de governança.
O objetivo nunca foi construir uma rede social dentro da plataforma.
A comunidade foi organizada por trilha e contexto de aprendizagem. Quando a possibilidade de conexão entre alunos entrou no produto, consentimento e isolamento deixaram de ser detalhes.
Esse fluxo já atravessou implementação e validação em produção com consentimento explícito dos dois participantes e decisões humanas.

Use uma captura que mostre comunidade ou conexão por consentimento explícito, sem telefone, e-mail ou outro dado pessoal.
- CAMINHO
- /images/portfolio/skalay-members/comunidade-consentimento-explicito.webp
- FORMATO
- WEBP
- TAMANHO
- 1600 × 1000 px
- PROPORÇÃO
- 8:5
- consentimento versionado dos dois participantes
- matrícula e contexto válidos
- nenhum contato externo exposto
- pedido, aceite e revogação humanos
- isolamento entre organizações preservado
- IA não cria a relação por conta própria
Foi uma das primeiras vezes em que uma ideia aparentemente simples mostrou, na prática, que interface costuma ser a última camada de uma regra.
11–12 / FRICÇÃO
Celular não é a versão menor. E o reprodutor de vídeo não deveria prender o produto a um fornecedor.
Se o aluno estuda pelo celular, começar pelo computador e adaptar depois é começar pela restrição errada.
O outro risco era estrutural: deixar a experiência inteira dependente da origem do vídeo.
A primeira versão operacional já trabalha com reprodutor e retomada, enquanto o contrato de evolução preserva a possibilidade de trocar ou ampliar provedores sem redesenhar a jornada do aluno.
Toque, retomada, espaço, conexão instável e contexto curto de uso entram antes da expansão para telas maiores.
A origem do vídeo pode mudar. A experiência do aluno não deveria mudar junto.
A ideia permanece posterior; custo e dependências precisam justificar o momento.
Infraestrutura importante não deveria transformar fornecedor em prisão.
13–14 / O CONTEÚDO TAMBÉM ENVELHECE
Um vídeo pode continuar funcionando tecnicamente e já estar errado.
Em saúde, direito, contabilidade, tecnologia e outras áreas reguladas, atualidade não é acabamento editorial.
Por isso, o conteúdo passou a ter ciclo de vida: versão, classificação e possibilidade de revisão.
A Fase 1 já materializou um ciclo editorial mínimo. A visão mais ampla continua distinguindo o que envelhece rápido do que permanece estável.
Revisão eventual. A base tende a permanecer válida por mais tempo.
Precisa de revisão em intervalo definido porque norma, ferramenta ou prática muda.
Mistura partes estáveis com trechos que exigem acompanhamento.
Planejado não significa implementado. Essa distinção é parte da própria disciplina do projeto.
15–18 / O PRODUTOR É O OUTRO USUÁRIO
Se o produtor recebe um gráfico e continua sem saber o que fazer, a plataforma só mudou a decoração do problema.
Pensar apenas no aluno seria construir metade do produto.
Quem produz precisa saber onde a jornada trava, o que merece revisão, quando o risco de evasão começa a subir e quais decisões comerciais continuam sob seu controle.
A primeira camada de indicadores já existe. As camadas mais ambiciosas continuam sendo construídas por dependência, não por ansiedade de funcionalidade.
Dados reais por organização para leitura do produto e da aprendizagem.
Pontuação explicável e calibração por organização em execução, sem transformar sugestão em ação automática.
Usar sinais por trecho para orientar revisão de conteúdo.
Transformar dúvidas e sugestões recorrentes em sinal para decisão de produto.

Prefira uma visão que mostre informação acionável, não apenas uma coleção de gráficos.
- CAMINHO
- /images/portfolio/skalay-members/painel-produtor.webp
- FORMATO
- WEBP
- TAMANHO
- 1600 × 1000 px
- PROPORÇÃO
- 8:5
O produtor controla seu modelo comercial. A plataforma precisa sustentar a operação, não substituí-la.
Um dashboard que não muda decisão é só decoração cara. E uma plataforma não precisa ocupar o lugar da estratégia comercial do produtor.
19 / POR BAIXO DA EXPERIÊNCIA
Uma plataforma para vários produtores não pode ser uma coleção de cópias independentes.
O Skalay foi estruturado para atender várias organizações na mesma infraestrutura.
Isso exige uma fundação que separe identidade, usuários, conteúdo, permissões e dados entre organizações antes de começar a empilhar inteligência por cima.
Controle de acesso por função, isolamento de dados, provisionamento, personalização de marca e auditoria deixaram de ser palavras de arquitetura e entraram na fundação real do produto.
- identidade própria
- usuários próprios
- conteúdo próprio
- permissões próprias
- dados isolados
- identidade própria
- usuários próprios
- conteúdo próprio
- permissões próprias
- dados isolados
- identidade própria
- usuários próprios
- conteúdo próprio
- permissões próprias
- dados isolados
Mesma infraestrutura não significa dados misturados. Escala começa pela fronteira que não pode ser atravessada.
20–22 / O QUE JÁ EXISTE DE VERDADE
O projeto já passou do protótipo. E ainda está longe de fingir que terminou.
Fundação e primeira versão operacional foram encerradas por validações próprias.
A camada de inteligência já colocou Tutor IA e comunidade em produção, enquanto retenção e calibração seguem em execução.
O restante continua sendo visão, trabalho futuro ou hipótese. É justamente essa diferença que o case precisa deixar visível.
- autenticação, sessão e controle de acesso
- isolamento entre organizações e provisionamento
- marca própria, permissões por plano, auditoria e consentimento
- Trilha → Curso → Aula
- reprodutor, progresso e retomada
- marcos de competência, certificado de participação, diagnóstico inicial e indicadores do produtor
- base de IA isolada por organização
- Tutor IA sustentado por fontes e rastreável
- comunidade com assistência de IA e conexão por consentimento explícito
- risco de evasão e calibração em evolução

Use uma tela real do produto que represente o estágio atual sem expor usuários, organizações, chaves ou informações internas.
- CAMINHO
- /images/portfolio/skalay-members/estado-produto-set-2026.webp
- FORMATO
- WEBP
- TAMANHO
- 1600 × 1000 px
- PROPORÇÃO
- 8:5
Estimativa editorial de materialização da visão fundacional em quatro macrofases; não representa percentual oficial de engenharia, linhas de código, tarefas ou horas trabalhadas.
- 01FundaçãoEncerrada
- 02MVP operacionalEncerrado
- 03Inteligência e engajamentoEm execução
- 04EscalaFutura
Software real possui bordas inacabadas. Esconder isso faria o projeto parecer mais pronto – e muito menos verdadeiro.
23–24 / O QUE MUDOU NO CAMINHO
Uma arquitetura não prova qualidade porque nunca mudou.
O planejamento inicial apostava numa abstração central obrigatória para o ecossistema. Na execução, essa hipótese foi revista quando a dependência começou a limitar a autonomia que deveria ajudar.
Também descobri que funcionalidades aparentemente pequenas escondem regras de autenticação, autorização, validade, auditoria e contexto.
Rever uma abstração deixou de parecer recuo. Passou a ser parte do trabalho.
Muitas funcionalidades são sistemas de regras disfarçados de interface.
25 / IA NÃO ESCREVE RESPONSABILIDADE
IA reduziu a distância entre decisão e construção. Não eliminou a necessidade de decidir direito.
O Skalay é construído intensamente com assistência de IA.
Isso mudou a velocidade com que consigo transformar regra em sistema, testar hipóteses e revisar implementação.
Mas velocidade não transfere responsabilidade.
- sugerir
- implementar
- testar
- refatorar
- documentar
- encontrar inconsistências
- definir política de acesso
- assumir privacidade
- decidir regra comercial
- aceitar risco de segurança
- responder pela experiência final
- substituir julgamento de produto
A ferramenta pode encurtar o caminho. A assinatura da decisão continua sendo humana.
26 / O QUE O SKALAY PROVA
Durante anos eu trabalhei com sistemas do outro lado. Agora consigo atravessar a tradução inteira.
Antes, eu definia necessidade, descrevia processo, cobrava fornecedor, testava e validava.
No Skalay, a tecnologia me permite materializar com mais proximidade aquilo que a experiência de gestão me ensinou a especificar.
Não é uma história sobre abandonar gestão para “virar programador”. É sobre diminuir a distância entre entender o problema e conseguir testá-lo em produto.
- 01PROBLEMA
O que está realmente acontecendo?
- 02REGRA
Que condição precisa ser verdadeira?
- 03ARQUITETURA
Onde essa regra deve viver para continuar coerente?
- 04DADOS
O que precisa existir, permanecer isolado e ser rastreável?
- 05INTERFACE
Como a regra aparece sem despejar complexidade no usuário?
- 06TESTE
Que evidência pode quebrar a hipótese antes da produção?
- 07DEPLOY
A mudança atravessa os gates e chega ao ambiente real.
- 08OPERAÇÃO
Uso real devolve novas restrições para a próxima decisão.
Software começa antes do código: começa nas regras.
27 / O QUE EU FARIA DIFERENTE
Eu separaria ainda mais cedo visão futura de escopo comprometido.
Quando se pensa um produto grande, é muito fácil transformar “isso seria interessante” em “isso precisa existir agora”.
Radar Legal, vitrine aberta de cursos, C3, uso sem conexão, infraestrutura própria de vídeo, mapa de calor da aprendizagem e previsão de evasão podem fazer sentido.
Isso não significa que todos merecem o mesmo momento.
01Isso é uma boa ideia?
02É a próxima coisa que precisamos construir?
A segunda pergunta é muito mais difícil.
28 / O QUE FICOU
O maior desafio não foi construir muitas funcionalidades. Foi impedir que muitas boas ideias fossem construídas na ordem errada.
O Skalay começou com uma visão grande.
Para virar software real, precisou aceitar que dependência vem antes de desejo.
Na documentação isso era uma ordem. Na execução, virou disciplina.
29 / VISÃO DE FUTURO
A visão continua grande. O compromisso não precisa ser.
Há ideias que continuam no horizonte. Algumas estão próximas. Outras permanecerão deliberadamente distantes até que a operação justifique trazê-las para frente.
O fato de uma ideia existir no mapa não significa que ela será construída exatamente como foi imaginada.
Produto também é aprender o que não construir.
DA DECISÃO À EXECUÇÃO
O player era apenas a parte visível.
Ao decompor os problemas reais do ensino online, entregar vídeos passou a parecer a parte mais simples.
Antes da construção, esses problemas foram transformados em 54 decisões estratégicas.
Escolha, abandono, dúvida, progresso, suporte, certificação, conteúdo e sustentabilidade precisavam ser separados antes de virar interface.
As decisões passaram a definir critérios, limites, permissões, responsabilidades e dependências.
Depois começou a parte difícil: transformar decisão em regra, regra em arquitetura e arquitetura em software.
Hoje o Skalay já possui fundação multi-tenant, conteúdo, player, progresso, milestones, certificação, inteligência e componentes comunitários em diferentes estágios de produção.
ESTADO DO PRODUTO · SETEMBRO/2026
É software real. E software real possui bordas inacabadas.
A Fundação e a primeira versão operacional foram materializadas.
A Fase de inteligência continua em construção.
A fase de escala permanece futura.
O percentual exibido no mapa de evolução é uma estimativa editorial de materialização da visão fundacional – não uma métrica formal de engenharia.PROJETO EM CONSTRUÇÃO
O Skalay ainda está em construção.
É justamente por isso que este case consegue mostrar decisão antes do código, mudança de hipótese, validação, regressão, segurança, QA, deploy e evolução.
A visão continua maior do que o escopo já materializado.
APRENDIZADO
Construir software também é escolher, repetidamente, o que ainda não construir.
O maior desafio não foi construir muitas funcionalidades.
Foi impedir que muitas boas ideias fossem construídas na ordem errada.
Fundação antes de inteligência. Operação antes de escala. Validação antes de expansão.