Enzo Zavorski / Luciano Bellaver / Julio Baptista / Marcos Rocha
Somos a equipe Clawler, no hackathon Solana e Cursor em Passo Fundo. O núcleo deste pitch é a notarização de aprovações na Solana, ligada à gestão local e ao Git. O notário já está implementado no código do produto. Ele registra a identificação da entidade aprovada e a referência do commit. O MVP não inclui IA integrada. A implementação foi inspecionada; a gravação e a transação que sustentam a demonstração ainda precisam ser verificadas.
02 / PROBLEMA
Qual commit entrega esta tarefa?
Tarefa, alteração e aprovação precisam contar a mesma história.
01
Tarefa
O que fazer.
02
Código
O que mudou.
03
Aprovação
O que foi aceito.
Quando esses registros se separam, reconstruir a entrega vira trabalho adicional.
Pense numa tarefa marcada como concluída. Qual alteração realmente a entregou? Onde está o registro de que aquela versão foi aceita? Quando gestão, código e aprovação ficam separados, alguém precisa reconstruir essa relação. Essa é a dor que orienta o produto. Não estamos atribuindo uma perda financeira medida a esse problema. Estamos concentrando a solução no vínculo entre os três registros, para que a entrega tenha um contexto rastreável.
03 / SOLUÇÃO
Aprovações registradas na Solana.
GESTÃO LOCAL
Tarefas + Git.
Tarefas, dependências e fluxo de aprovação.
Interface web · API · SQLite · Git
NÚCLEO DO MVP / IMPLEMENTADO
Solana.
Registrar a aprovação e o hash do commit.
Memo Program · Devnet
Tasks, milestones e projetos. O MVP não inclui IA integrada.
O Clawler conecta tarefas, dependências e aprovação ao Git. A notarização Solana é o núcleo deste MVP: o código implementa o envio de um Memo com a identificação da entidade, o hash do commit e o estado COMPLETED. A API chama esse notário ao concluir tasks por merge e ao aprovar milestones e projetos. Assim, existe um mecanismo para relacionar uma aprovação local a um registro consultável na rede. Inspecionamos a implementação no commit f8574da; isso não equivale a confirmar uma transação real ou a medir confiabilidade. O MVP não possui IA integrada. Assentos para agentes fazem parte do modelo comercial, não de um motor de IA embarcado.
04 / ARQUITETURA
Da aprovação local ao registro na Solana.
INTERFACE
Web
Tarefas e aprovações
→
NÚCLEO LOCAL
API / FastAPI
Regras do fluxo
→
PERSISTÊNCIA
SQLite + Git
Estado e código
Aprovação / merge → COMPLETED
SOLANA / DEVNET
Memo Program
Tipo + UUID + commit + status
Código implementado. Transação da demo a verificar.
Assinatura pelo Clawler.
Uma carteira dev compartilhada.
Não comprova identidade individual nem qualidade da entrega.
A interface conversa com a API local, que usa SQLite e Git. Quando a aprovação ou o merge leva uma entidade a COMPLETED, o notário constrói o Memo CLAWLER_PROOF com tipo, UUID, hash do commit e status. O código envia essa mensagem ao Memo Program; a configuração padrão usa Devnet. O pagador é a carteira configurada no Clawler, compartilhada no MVP, não a carteira pessoal de cada usuário. O payload não inclui o código-fonte nem o corpo da tarefa. A aprovação local pode terminar mesmo quando a notarização é pulada ou falha. Receber uma assinatura do envio também não comprova confirmação final na rede. Para a demo, ainda falta verificar a transação correspondente à aprovação mostrada. Esse registro não certifica a identidade de uma pessoa nem a qualidade do trabalho.
05 / TAM · CONTEXTO SETORIAL
DevSecOps global.
2024 · ESTIMATIVA
8,5US$ bilhões
→
2030 · PROJEÇÃO
20,2US$ bilhões
Um setor que reúne desenvolvimento, segurança e operações.
Referência ampla de mercado. Não equivale ao mercado capturável pelo Clawler.
Para situar a oportunidade, usamos uma única fonte e um único recorte: o mercado global de DevSecOps. A Grand View Research estima oito bilhões e meio de dólares em 2024 e projeta vinte bilhões e duzentos milhões em 2030. É um contexto setorial amplo. Não estamos somando mercados de IA, nem dizendo que todo esse valor é endereçável pelo Clawler.
06 / SAM · SEGMENTO ATENDÍVEL
Desenvolvedores e pequenas empresas.
01
Brasil como recorte inicial.
02
Equipes de software que usam Git.
03
Assentos humanos e bots no modelo pago.
Recorte definido; dimensionamento pendente. Sem estimativa de receita endereçável validada.
O mercado atendível começa por desenvolvedores independentes e pequenas empresas de software no Brasil que precisam de gestão vinculada ao Git. O dimensionamento será de baixo para cima: quantidade de clientes elegíveis e assentos, multiplicada pelo preço anual de cada plano. Um assento pode ser ocupado por humano ou bot, ao mesmo preço dentro do plano. Precisamos de uma base para a quantidade de empresas, de individuais e de assentos, sem dupla contagem. Não presumimos vinte assentos ou uma quantidade de bots por empresa como média de mercado. Ainda não temos esse dimensionamento validado. Estatísticas de segurança e o total de DevSecOps na América Latina não substituem o cálculo do SAM.
07 / SOM · META DE ADOÇÃO
Meta inicial de adoção
META ESTIMADA
500usuários no total
/
APÓS O LANÇAMENTO
6meses
Desenvolvedores e pequenas empresas de software no Brasil.
Meta, não tração comprovada. Não são 500 pagantes. Divisão gratuito/pago e receita ainda não definidas.
A meta estimada aprovada pela equipe é chegar a quinhentos usuários no total nos primeiros seis meses após o lançamento. Esse número substitui as estimativas anteriores de mil e de seiscentos e cinquenta usuários. Não significa quinhentos pagantes nem quinhentos usuários ativos medidos. A divisão entre gratuitos e pagos ainda não foi definida, então não associamos uma receita a essa meta. Ela orienta a adoção inicial entre desenvolvedores e pequenas empresas brasileiras, mas ainda não constitui um SOM financeiro dimensionado. O MVP permanece sem IA integrada. A estratégia de aquisição será detalhada para o pitch final.
08 / EQUIPE
Clawler.
01Enzo Zavorski
02Luciano Bellaver
03Julio Baptista
04Marcos Rocha
Esta é a equipe Clawler: Enzo Zavorski, Luciano Bellaver, Julio Baptista e Marcos Rocha. Estamos reunindo a direção do produto e a preparação desta apresentação para o hackathon em Passo Fundo. Nosso foco é conectar gestão local, Git e notarização Solana. O compromisso é apresentar a implementação existente com limites claros, diferenciar metas de resultados e sustentar a demonstração com evidência verificável.
09 / PRÓXIMOS PASSOS E PLANOS
Modelo comercial
BÁSICO / PESSOAL
US$ 6/ mês
Desenvolvedores individuais e freelancers.
TEAMS / ENTERPRISE
US$ 25/ assento / mês
Humano ou bot. Mesmo preço por assento.
Assinatura SaaS planejada: autenticação e nuvem. Preço definido não implica IA integrada no MVP.
Próximo passo: demonstrar o fluxo Solana e validar a oferta paga.
O modelo comercial definido pelo Enzo é uma assinatura SaaS, com autenticação centralizada e serviços de nuvem planejados. O plano Básico ou Pessoal custa seis dólares mensais. O Teams ou Enterprise custa vinte e cinco dólares por assento por mês. No modelo de cobrança, cada usuário ocupa um assento, seja humano ou bot, sem diferença de preço pela natureza do ocupante. Adicionar um agente significa adicionar um assento; não significa que o MVP ofereça um motor de IA integrado ou inclua custos de inferência. A oferta paga é uma etapa comercial a validar, não uma receita já existente. O próximo passo é demonstrar o fluxo Solana com sua transação e validar a oferta. Os canais de divulgação ficam para o pitch final.
10 / CONVITE
Vamos desenvolver o próximo passo do Clawler.
Investimento.Apoio técnico.Parcerias.
Para levar a notarização Solana à rotina das equipes de software.
github.com/ScorphionZ/Clawler ↗Buscamos investimento, apoio técnico e parcerias para levar a notarização Solana à rotina das equipes de software, conectada à gestão local e ao Git. A implementação existe; queremos demonstrar o fluxo e validar a oferta comercial. Nossa meta inicial é de quinhentos usuários totais em seis meses, sem alegar receita ou tração conquistada. O repositório está no slide para quem quiser examinar o trabalho. Não apresentamos um valor de aporte ou uma parceria fechada. Obrigado: somos a equipe Clawler.