4

De founder para founder:

Legal demais. Talvez seja o projeto com maior potencial real que já vi em pitches aqui no TabNews.

Primeiro o choque de realidade. Construir a tecnologia é a parte fácil. O verdadeiro desafio do Dalivim vai ser distribuição, vendas e modelo de negócios. Se você ficar preso no plano de R$ 49/mês para professores de computação, você terá um excelente projeto de estimação, mas nunca uma empresa de verdade.

Alguns pontos para você refletir:

  1. Internacionalização desde o dia 1: Esse problema não é local, é global. Universidades do mundo inteiro estão lidando exatamente com o mesmo "teatro acadêmico". Não limite seu mercado ao Brasil. Traduza o produto e a comunicação para o inglês imediatamente.

  2. Fuja da armadilha do B2C: Professor universitário não tem orçamento próprio relevante. Se você cobrar R$ 49/mês, precisará de milhares de clientes para pagar suas contas. O caminho é o B2B Enterprise: vender licenças anuais de milhares de dinheiros diretamente para os diretores de departamentos de tecnologia ou reitorias das faculdades.

  3. O Pitch para a Y Combinator e afins (A "Turnitin da era da IA"): Para atrair grandes aceleradoras você não pode se apresentar apenas como "um replay de código para aulas de computação" (mercado muito pequeno). O pitch precisa ser "Infraestrutura de integridade acadêmica na era da IA".

    • Expanda para validar qualquer produção de texto digital. Lembre-se: a Turnitin (ferramenta de plágio tradicional) foi adquirida por US$ 1,75 bilhão porque ela valida a autoria em qualquer disciplina. O Dalivim pode ser a Turnitin da era generativa?!

  4. O calcanhar de Aquiles dos gigantes: A Turnitin e todos os outros incumbentes estão correndo desesperadamente para criar "detectores de IA", mas eles estão caindo na armadilha óbvia de tentar analisar o resultado final. O diferencial do Dalivim é real. Mudar a infraestrutura de gigantes que foram construídas em cima de upload de arquivos para monitoramento de sessão em tempo real é um pesadelo para eles. A lentidão dos incumbentes é a sua janela de oportunidade. Não demore. Um programa de aceleração é questão de sobrevivência.

  5. Open-Core e Self-Hosted é obrigatorio: Instituições de ensino são extremamente burocráticas com privacidade de dados de alunos (como a LGPD/GDPR). Oferecer uma versão community gratuita e self-hosted (que o próprio professor possa rodar no servidor da faculdade) é a única forma de driblar a burocracia de TI, conseguir adoção orgânica rápida e criar defensores da sua marca lá dentro.

  6. Foco comercial e Sociedade: O ambiente acadêmico é notoriamente difícil de penetrar, lento e político. Produto bom não se vende sozinho. Busque o quanto antes um sócio comercial forte, com experiência comprovada em vender tecnologia para instituições de ensino. E não tenha medo de oferecer uma fatia generosa da empresa, no mínimo uns 30% de equity, estruturado com cláusulas de vesting. É muito melhor ter 70% de um negócio real do que 100% de um projeto que ninguém usa.

Sendo bem pragmático, a estatística diz que a maioria desses projetos de faculdade acaba virando apenas uma ferramenta interna da própria universidade do criador. Mas se você conseguir olhar além do código, estruturar um modelo B2B agressivo e mirar no mercado global, o potencial de escala e de um eventual exit bem gordo é real.

O jogo agora é sobre negócios, não sobre código. Muito sucesso na jornada!

Carregando publicação patrocinada...
2

Adorei seu comentário e os pontos citados. Vou responder por tópicos.

  1. A ideia principal sempre foi expandir internacionalmente, mas queria validar localmente num ambiente real, como estou fazendo agora.

  2. O modelo B2C atual parte da mesma premissa da resposta anterior, atrair professores para validar em suas universidades locais. O correto é realmente como você orientou, vender para B2B.

  3. É o caminho correto a seguir, validando a ferramenta primeiro. Especificamente sobre o mercado de recrutamento técnico, a arquitetura do Dalivim foi construída para lidar com diferentes cenários, é desacoplada e dividida em três serviços com responsabilidades bem definidas. O backend educacional (BFF) é a única camada que conhece professor, aluno e turma: ele cuida de autenticação, permissões e traduz esse vocabulário para conceitos neutros antes de falar com o resto do sistema. O engine é um serviço separado, com API e banco de dados próprios, que faz o trabalho pesado: ingestão de telemetria, análise de rastreabilidade, replay e geração de evidências, tudo em termos genéricos (sujeito, item de trabalho, sessão rastreada), multi-tenant desde a primeira migração e sem uma linha de vocabulário educacional. O processamento assíncrono roda num worker com outbox transacional, então nenhuma submissão se perde entre serviços. O produto de educação é um cliente do engine, não o engine em si. Um vertical de recrutamento técnico seria um segundo cliente da mesma API: outro tenant, outro vocabulário (candidato, desafio, entrevista), mesma análise, mesmo replay, mesma execução segura. Nada precisa ser reescrito; precisa ser conectado.

  4. Especificamente sobre o Turnitin e outras empresas, é verdade que nenhuma delas fez algo desse nível. Se concentram em avaliar o arquivo pronto, que é simplesmente adivinhação.

  5. Dalivim é self-hosted, nenhum dado é enviado para ferramentas ou empresas externas, o code runner principal do dalivim é uma sandbox particular, construído em Go, baseada em nsjail e csgroup. Exceto os códigos que rodam React e afins, esses dependem de outra biblioteca chamada Sandpack, que também é self-hosted. Esses códigos obviamente rodam numa instância particular, longe do servidor principal. Dalivim também segue a LGPD desde o primeiro dia. Alguns dados têm prazos de exclusão obrigatória, telemetria bruta e snapshots de código expiram sozinhos em janelas configuráveis (90 a 365 dias, conforme a sensibilidade), e o sistema se recusa a subir em produção com essa limpeza desligada. Antes de qualquer coleta, o aluno vê um aviso claro do que será registrado e por quê, e a versão exata do texto que ele aceitou fica guardada com hash e data, dá para provar depois o que foi mostrado. E o mais importante: o que nunca entra no sistema. Conteúdo da área de transferência, teclas digitadas, webcam, gravação de tela nada disso é coletado, e não por promessa: o servidor descarta na entrada qualquer coisa fora de uma lista fechada de métricas numéricas. A instituição é a controladora dos dados e tem à disposição exclusão e anonimização por aluno, registradas em trilha auditável. Mas confesso que falta revisão jurídica formal, contrato de operador, política publicada, o rito todo.

  6. É atualmente meu ponto fraco, não sou experiente com isso. Principalmente nesse mercado de edtech. Vou ter que buscar um parceiro comercial se quiser levar essa ideia verdadeiramente longe.