Pular para o conteúdo
← Início

// todos os projetos

Tudo que eu construí

Todos os projetos, os mais fortes primeiro — inclusive os menores, que não aparecem na página inicial.

Dashboard de execução orçamentária do SIMF: empenhado, liquidado a pagar e saldo bancário sobre uma tabela de empenhos por credor e processo.

SIMF

estudo de caso

Sistema Interno de Gestão Financeira

Plataforma web interna que monitora a execução orçamentária e financeira da Secretaria de Educação do Pará. Projeto âncora — sou o tech lead e product owner.

  • Next.js 15
  • React
  • Tailwind
  • Supabase
  • PostgreSQL

Estudo de caso →

● Sistema de governo privado — apenas estudo de caso, com capturas de tela de dados fictícios. Nenhum código ou dado real é publicado.

problema
A execução orçamentária e financeira era acompanhada em ferramentas espalhadas, sem uma visão única em tempo real para os diretores que respondem por ela.
solução
Uma plataforma web com controle de acesso por perfil que lê os dados do SIAFE em tempo real, com módulos de execução orçamentária, liquidações, pagamentos e contas bancárias — em uso ativo pela DFIN e pela DPPC.
impacto
Em uso ativo em produção, atendendo a SAPF. Implantado em VM Ubuntu (Nginx + PM2) atrás de DNS interno com SSL.
Livro caixa do ClickContas: lançamentos do mês com saldo transportado, totais de entradas e saídas, e coluna de saldo corrente.

ClickContas

em produção

SaaS contábil modular

Plataforma multiempresa que digitaliza a rotina de um escritório de contabilidade: a IA lê folhas de ponto manuscritas, e um livro caixa compartilhado deixa cada empresa-cliente lançar o próprio movimento para a contadora conciliar.

  • Next.js
  • TypeScript
  • React
  • Tailwind
  • PostgreSQL (Supabase)
  • Google Sheets API
  • Google Gemini
  • Vercel

Estudo de caso →

● Produto de cliente privado — apenas estudo de caso, com mockups de dados fictícios das telas reais.

problema
O escritório tocava duas rotinas no braço: redigitar numa planilha, uma a uma, as folhas de ponto manuscritas que chegavam por foto, e lançar a movimentação de caixa de cada cliente que vinha por WhatsApp ou papel — sem padronização e sem visão consolidada.
solução
Dois módulos independentes numa plataforma multiempresa. O Gemini lê a folha fotografada e uma tela de revisão lado a lado aplica as regras de negócio; a empresa-cliente lança o próprio caixa contra um plano de contas padronizado pela contadora, que concilia e fecha o mês.
impacto
Em produção com clientes reais. O que antes era redigitação virou conferência, e o ciclo se fecha sozinho: o sistema gera a folha em branco, o cliente preenche à mão, a foto volta, e a planilha sai pronta.
Painel da coordenação do Balcão de Atendimento, mostrando escolas agendadas, ocupação de vagas por dia e convocações pendentes.

Balcão de Atendimento

em produção

Agendamento e prova de atendimento

Plataforma full-stack que agenda ~110 escolas em 200 vagas presenciais e transforma cada atendimento em prova auditável para órgãos de controle. Construída e publicada sozinho.

  • Next.js
  • TypeScript
  • PostgreSQL
  • Drizzle ORM
  • Tailwind
  • Docker

Estudo de caso →

GitHub ↗

● O repositório público é uma versão de demonstração com dados fictícios — a instância de produção é interna.

problema
As escolas afirmavam aos órgãos de controle que não eram orientadas sobre como prestar contas de recursos federais; a secretaria afirmava que orientava. Faltava prova para os dois lados.
solução
Cada atendimento vira um registro imutável, com autor e data — correções entram como adendo assinado, nunca sobrescrevendo o original. As escolas agendam por um link com token assinado, sem senha; coordenação e analistas têm seus próprios perfis.
impacto
Em produção. As regras que importam moram no banco, não só na aplicação: índices únicos parciais tornam impossível uma vaga dobrada. Publicado em um banco corporativo compartilhado, atrás de um proxy reverso que eu não controlava.
Home da loja Sensse: cabeçalho da marca, banner de entrega no mesmo dia na região, posts editoriais e categorias de produto.

Sensse

em produção

E-commerce próprio, do catálogo ao back-office

Loja de bem-estar sexual em produção: catálogo, checkout Pix e cartão, frete por CEP, estoque reservado junto com a cobrança e um back-office que os donos tocam sozinhos.

  • Next.js 16
  • TypeScript
  • Tailwind v4
  • PostgreSQL (Supabase)
  • Row Level Security
  • Mercado Pago
  • Melhor Envio
  • Vercel

Estudo de caso →

Site ↗GitHub ↗

● O repositório público é o código de produção recortado para portfólio; as telas são mockups com dados fictícios e arte neutra no lugar do produto.

problema
A loja vendia por WhatsApp, uma conversa por vez — consultar preço, calcular frete, mandar chave Pix, conferir se caiu, anotar o estoque num caderno. Isso limita as vendas ao número de mensagens que uma pessoa consegue responder, e não deixa histórico do que sai nem de onde vem quem compra.
solução
Uma loja completa construída do zero em Next.js com Postgres próprio: catálogo com variações e estoque, busca, favoritos, carrinho, checkout com Pix (QR que expira) e cartão, frete por CEP com entrega no mesmo dia na região, área do cliente, blog editorial com painel de publicação, e um back-office que cobre pedidos, estoque com custo e validade, financeiro, cupons de influenciador e recuperação de carrinho.
impacto
Em produção em sensse.com.br, atendendo Belém, Ananindeua e Marituba com entrega no mesmo dia e o resto do Brasil pelos Correios. A operação inteira — produtos, estoque, despacho, financeiro e conteúdo — é tocada pelos donos no painel, sem desenvolvedor no meio.
A grade da vitrine num celular: vinte cards de produto endereçados de A1 a E4, cada um com preço e botão ADD.

Cherry Bomb Vending Machine

em construção

Full-stack / IoT

Uma máquina de vendas por QR Code para produtos artesanais: um Pix cobre a sacola inteira, e só o webhook de pagamento pode mexer no estoque.

  • FastAPI
  • Python 3.11
  • PostgreSQL
  • psycopg2
  • Mercado Pago (Pix)
  • Cloudinary
  • Tailwind CSS
  • Vanilla JS
  • Railway
  • ESP32 / MQTT

Estudo de caso →

● O repositório é público, mas este estudo de caso sai sem link enquanto uma credencial encontrada na documentação dele é rotacionada.

problema
Vender peças artesanais em condomínios significa ficar horas ao lado de uma mesa ou confiar numa caixinha de honestidade. Uma máquina de vendas convencional não resolve: a maquininha cobra mensalidade e uma fatia por transação que uma presilha de R$ 8,50 não absorve, e dinheiro em espécie precisa ser recolhido e guardado. A máquina precisava vender vinte itens distintos, sem ninguém por perto, entre R$ 5,50 e R$ 24,50, sem hardware nenhum no caminho do cliente.
solução
O terminal de pagamento saiu da máquina e virou um adesivo. Um QR Code no vidro abre uma vitrine mobile que espelha o layout físico — uma grade 4×5 em que cada card é uma mola real, endereçada de A1 a E4. O cliente enche a sacola com vários slots e paga um único Pix pelo carrinho inteiro: o backend soma no servidor, pede uma cobrança só ao Mercado Pago, e espera. Nada do pedido é considerado verdade até o webhook dizer que foi aprovado.
impacto
Não medido, e propositalmente não afirmado. O caminho de software roda em produção de ponta a ponta — vitrine, cobrança Pix, webhook de confirmação, baixa de estoque — mas a liberação física não está implementada: o arquivo de firmware do ESP32 está vazio e não existe publisher MQTT. O resumo honesto é um sistema de pagamento e estoque funcionando em produção, preso a uma máquina que ainda não gira as molas. Qualquer número de vendas seria ficção.