close

disponível para oportunidades e freelas

Construo sistemas web que
saem do seu ambiente local:
API, interface, banco e deploy.

Sou Jonas Filho, desenvolvedor FullStack. Meu trabalho está em projetos que rodam no ar, com banco de dados, autenticação e publicação automatizada, em vez de exercícios de curso. Escolhi Node, React e PostgreSQL porque é o que aparece quando a feature precisa funcionar fora do meu computador.

Projetos

Três sistemas que resolveram um problema real

Descrevo cada um pelo problema que ele resolve e pela decisão que precisei tomar. A lista de tecnologias fica no fim do card porque é consequência, não argumento.

01

Central de Operações

sistema interno · no ar

O problema

Eu precisava de um lugar único onde ver o que estava acontecendo nos meus projetos e no meu servidor: o que foi publicado, o que falhou, o que estava em andamento. Tudo espalhado em terminal, log e memória de agente.

O que foi construído

Um portal com nginx e TLS que recebe publicações automatizadas, indexa cada atividade, mantém histórico do que foi feito e registra relatórios. Publicar virou um comando com validação, commit e verificação de que a versão que subiu é a que está no disco.

Decisões técnicas
  • Autenticação em toda a área pública, com verificação no servidor
  • Publicação em worktree: a edição já está no ar quando o deploy termina
  • Vitrine pública separada da instância real, gerada por script num sentido só
  • nginx
  • TLS
  • Bash
  • Git
  • Agente de IA
02

DevBurguer

e-commerce fullstack · no ar

O problema

Um projeto de curso que eu levei além do enunciado: uma loja completa, com cadastro de usuário, catálogo, carrinho e pagamento, e não só a parte visual que o exercício pede.

O que foi construído

Duas bases separadas. A interface em React com Material UI, validação de formulário, carrousel de categorias e checkout com Stripe. A API em Node e Express, com duas camadas de banco (MongoDB por Mongoose e Postgres por Sequelize), autenticação JWT, upload de imagem em Cloudinary e tratamento de erro.

Decisões técnicas
  • API separada da interface, com contrato definido entre as duas
  • Token JWT com middlewares de autenticação e de perfil de administrador
  • Upload de imagem resolvido depois de três tentativas. O registro do que deu errado está no histórico de commits
  • React
  • Node.js
  • Express
  • MongoDB
  • PostgreSQL
  • JWT
  • Stripe
03

Inventory Genius

controle de estoque · typescript

O problema

Controle de material em um negócio pequeno costuma ser uma planilha: nenhuma rastreabilidade de entrada e saída, nenhum histórico de alteração e nenhum aviso quando o estoque sai do lugar.

O que foi construído

Sistema em TypeScript com PostgreSQL para registrar produtos, seus materiais e a relação entre os dois. A interface usa shadcn/ui sobre React, com formulários de produto e de material e o controle de quanto de cada material está vinculado a cada produto.

Decisões técnicas
  • Modelagem relacional de produto, material e o vínculo entre os dois
  • TypeScript no lugar de JavaScript justamente porque o domínio tem muitos campos
  • Componentes de formulário separados da regra de negócio
  • TypeScript
  • PostgreSQL
  • React
  • shadcn/ui

Começou como um projeto gerado com Lovable e refiz a parte de dados. É o que mais usei TypeScript até agora.

Tem mais código no meu GitHubOs exercícios de curso que comecei, e o que estou construindo agora.

IA e automação

Onde o modelo é peça do processo, não demonstração

Dois sistemas em que a IA executa trabalho de verdade: um agente que roda rotinas agendadas no servidor e um pipeline que gera, verifica e publica conteúdo. Em ambos, o número de uso está medido, não estimado.

01

Agente de automação

agente com ferramentas · 25 rotinas no ar

Boa parte do que eu fazia à mão tinha sempre o mesmo formato: ler uma fonte, decidir com algum critério, executar e registrar o que aconteceu. Script comum não dava conta, porque a decisão muda de caso para caso e a fonte nem sempre oferece API.

Um agente que roda em VPS própria, com ferramentas de arquivo, terminal, navegador e APIs externas, memória entre sessões e procedimentos carregados conforme a tarefa. Hoje são 25 rotinas agendadas, entre publicação em quatro horários, vigilância de fonte externa, relatório semanal e backup. Cada execução passa pelo portal interno, que já registrou 217 publicações.

  • Procedimento em arquivo em vez de um prompt gigante: cada tarefa carrega só a instrução que importa, o que reduz erro e custo por execução
  • Ferramenta com poder de escrita pede permissão: publicar, gastar e apagar continuam exigindo aprovação explícita
  • Rotina agendada valida antes de publicar e confere se a versão no ar é a que está no disco
  • Python
  • Node.js
  • APIs de LLM
  • Chamada de ferramentas
  • nginx
  • systemd
  • PostgreSQL
  • Bash
02

Pipeline de conteúdo

imagem, voz e vídeo · custo medido

Uma peça de rede social por dia não caberia se cada etapa fosse manual: escrever, desenhar, revisar, narrar e montar o vídeo. O gargalo era o tempo de produção, não a falta de ideia.

Pipeline que transforma um tema em peça publicada. O roteiro sai do modelo, a imagem vem de uma API de difusão, a peça passa por verificação automática, a narração é sintetizada em voz e o vídeo vertical é montado por linha de comando. Quando o texto precisa ficar em posição exata, a arte é gerada em HTML e capturada por navegador headless, porque modelo de imagem erra tipografia.

  • Verificação antes de publicar: o script mede margem, corte e espessura por pixel, porque conferir no olho e pedir isso a um modelo de visão erram nesse tipo de checagem
  • Custo por peça medido, não estimado: cerca de US$ 0,03 por imagem gerada, acompanhado a cada lote
  • Cada ferramenta no que ela faz melhor: modelo para imagem, HTML e CSS para texto em posição fixa
  • Python
  • API de imagem
  • LLM
  • TTS
  • ffmpeg
  • Chromium headless
  • cron

Como eu trabalho

Três decisões que se repetem em cada projeto

  1. 01

    Entendo o problema antes de escolher a ferramenta

    Qualquer projeto começa por saber o que precisa acontecer, não por decidir se uso React ou CSS. A escolha da stack é consequência da restrição: volume de dados, quem vai manter, o que já existe rodando.

  2. 02

    Construo a parte que dá problema primeiro

    Autenticação, banco, upload e deploy são onde o software quebra. Faço esses dois dias de trabalho antes de polir tela, porque descobrir um problema de permissão depois da interface pronta custa dez vezes mais.

  3. 03

    Deploy é parte do trabalho, não o final

    Se não está no ar, não está pronto. Versiono, publico, verifico que a versão no servidor é a que está no meu disco. Foi assim que a Central de Operações deixou de ser um projeto local.

Jonas Filho

Sobre

Aprendizado em público, do jeito que dá para manter

Comecei nos exercícios do curso e eles continuam no GitHub: o histórico de como alguém evolui diz mais do que uma lista de front-end. O que me levou adiante foi querer ver as coisas funcionando fora do meu notebook, e é por isso que a Central de Operações existe.

Onde
Minas Gerais
Formação
Faculdade Pitágoras Anhanguera Unopar
Curso
Ciências da Computação
Estudo
DevClub
Certificações
Credly
Stack
Node · React · TypeScript

Contato

Se a sua vaga ou projeto precisa de alguém que entrega o que está no ar, vamos conversar.

Prefiro WhatsApp, mas qualquer canal funciona. Se você tem um problema técnico em mente, escreva o que ele é em uma frase. Para mim vale mais do que um currículo.