disponible para puestos y proyectos freelance

Construyo sistemas web que
salen de tu entorno local:
API, interfaz, base de datos y deploy.

Soy Jonas Filho, desarrollador FullStack. Mi trabajo está en proyectos que funcionan en producción, con base de datos, autenticación y publicación automatizada, en lugar de ejercicios de curso. Elegí Node, React y PostgreSQL porque es lo que aparece cuando la funcionalidad tiene que funcionar fuera de mi computadora.

Proyectos

Tres sistemas que resolvieron un problema real

Describo cada uno por el problema que resuelve y por la decisión que tuve que tomar. La lista de tecnologías va al final de la tarjeta porque es consecuencia, no argumento.

01

Central de Operações

sistema interno · en el aire

El problema

Necesitaba un lugar único donde ver qué pasaba en mis proyectos y en mi servidor: lo que se publicó, lo que falló, lo que estaba en curso. Todo repartido entre terminal, logs y memoria del agente.

Lo que se construyó

Un portal con nginx y TLS que recibe publicaciones automatizadas, indexa cada actividad, mantiene el historial de lo hecho y registra informes. Publicar se volvió un comando con validación, commit y verificación de que la versión que subió es la que está en el disco.

Decisiones técnicas
  • Autenticación en toda el área pública, con verificación en el servidor
  • Publicación en worktree: la edición ya está en línea cuando termina el deploy
  • Vitrina pública separada de la instancia real, generada por script en un solo sentido
  • nginx
  • TLS
  • Bash
  • Git
  • Agente de IA
02

DevBurguer

e-commerce fullstack · en el aire

El problema

Un proyecto de curso que llevé más allá del enunciado: una tienda completa, con registro de usuario, catálogo, carrito y pago, y no solo la parte visual que pide el ejercicio.

Lo que se construyó

Dos bases separadas. La interfaz en React con Material UI, validación de formulario, carrusel de categorías y checkout con Stripe. La API en Node y Express, con dos capas de base de datos (MongoDB por Mongoose y Postgres por Sequelize), autenticación JWT, subida de imagen a Cloudinary y manejo de errores.

Decisiones técnicas
  • API separada de la interfaz, con contrato definido entre las dos
  • Token JWT con middlewares de autenticación y de perfil de administrador
  • Subida de imagen resuelta después de tres intentos. El registro de lo que falló está en el historial de commits
  • React
  • Node.js
  • Express
  • MongoDB
  • PostgreSQL
  • JWT
  • Stripe
03

Inventory Genius

control de stock · typescript

El problema

El control de material en un negocio pequeño suele ser una planilla: sin trazabilidad de lo que entra y sale, sin historial de cambios y sin aviso cuando el stock se desvía.

Lo que se construyó

Sistema en TypeScript con PostgreSQL para registrar productos, sus materiales y la relación entre los dos. La interfaz usa shadcn/ui sobre React, con formularios de producto y de material y el control de cuánto de cada material está vinculado a cada producto.

Decisiones técnicas
  • Modelado relacional de producto, material y el vínculo entre los dos
  • TypeScript en lugar de JavaScript justamente porque el dominio tiene muchos campos
  • Componentes de formulario separados de la regla de negocio
  • TypeScript
  • PostgreSQL
  • React
  • shadcn/ui

Empezó como un proyecto generado con Lovable y rehice la parte de datos. Es donde más he usado TypeScript hasta ahora.

Hay más código en mi GitHubLos ejercicios de curso con los que empecé, y lo que estoy construyendo ahora.

IA y automatización

Donde el modelo es parte del proceso, no una demostración

Dos sistemas donde la IA hace trabajo real: un agente que ejecuta rutinas agendadas en el servidor y un pipeline que genera, verifica y publica contenido. En ambos, el número de uso está medido, no estimado.

01

Agente de automatización

agente con herramientas · 25 rutinas en línea

Buena parte de lo que hacía a mano tenía siempre la misma forma: leer una fuente, decidir con algún criterio, ejecutar y registrar lo que pasó. Un script común no alcanzaba, porque la decisión cambia de caso a caso y la fuente no siempre ofrece API.

Un agente que corre en su propia VPS, con herramientas de archivo, terminal, navegador y APIs externas, memoria entre sesiones y procedimientos cargados según la tarea. Hoy son 25 rutinas agendadas, entre publicación en cuatro horarios, vigilancia de fuente externa, informe semanal y backup. Cada ejecución pasa por el portal interno, que ya registró 217 publicaciones.

  • Procedimiento en archivo en lugar de un prompt gigante: cada tarea carga solo la instrucción que importa, lo que reduce error y costo por ejecución
  • Una herramienta con poder de escritura pide permiso: publicar, gastar y borrar siguen exigiendo aprobación explícita
  • La rutina agendada valida antes de publicar y comprueba si la versión en línea es la que está en el disco
  • Python
  • Node.js
  • APIs de LLM
  • Llamada de herramientas
  • nginx
  • systemd
  • PostgreSQL
  • Bash
02

Pipeline de contenido

imagen, voz y video · costo medido

Una pieza de red social por día no cabría si cada etapa fuera manual: escribir, diseñar, revisar, narrar y montar el video. El cuello de botella era el tiempo de producción, no la falta de idea.

Pipeline que convierte un tema en pieza publicada. El guion sale del modelo, la imagen viene de una API de difusión, la pieza pasa por verificación automática, la narración se sintetiza en voz y el video vertical se monta por línea de comandos. Cuando el texto necesita quedar en una posición exacta, el arte se genera en HTML y se captura con navegador headless, porque el modelo de imagen se equivoca en tipografía.

  • Verificación antes de publicar: el script mide margen, corte y grosor por píxel, porque revisar a ojo y pedir eso a un modelo de visión fallan en este tipo de control
  • Costo por pieza medido, no estimado: cerca de US$ 0,03 por imagen generada, seguido en cada lote
  • Cada herramienta en lo que hace mejor: modelo para imagen, HTML y CSS para texto en posición fija
  • Python
  • API de imagen
  • LLM
  • TTS
  • ffmpeg
  • Chromium headless
  • cron

Cómo trabajo

Tres decisiones que se repiten en cada proyecto

  1. 01

    Entiendo el problema antes de elegir la herramienta

    Todo proyecto empieza por saber qué tiene que pasar, no por decidir si uso React o CSS. La elección del stack es consecuencia de la restricción: volumen de datos, quién lo va a mantener, qué ya está funcionando.

  2. 02

    Construyo primero la parte que da problemas

    Autenticación, base de datos, subida de archivos y deploy son donde el software se rompe. Hago esos dos días de trabajo antes de pulir pantalla, porque descubrir un problema de permisos con la interfaz terminada cuesta diez veces más.

  3. 03

    El deploy es parte del trabajo, no el final

    Si no está en línea, no está listo. Versiono, publico y verifico que la versión del servidor sea la que está en mi disco. Así fue como Central de Operações dejó de ser un proyecto local.

Jonas Filho

Sobre mí

Aprendizaje en público, de la forma que se puede sostener

Empecé con los ejercicios del curso y siguen en GitHub: el historial de cómo evoluciona alguien dice más que una lista de front-end. Lo que me llevó adelante fue querer ver las cosas funcionando fuera de mi notebook, y por eso existe Central de Operações.

Dónde
Minas Gerais, Brasil
Formación
Faculdade Pitágoras Anhanguera Unopar
Carrera
Ciencias de la Computación
Estudio
DevClub
Certificaciones
Credly
Stack
Node · React · TypeScript

Contacto

Si tu puesto o proyecto necesita a alguien que entrega lo que está en línea, hablemos.

Prefiero WhatsApp, pero cualquier canal funciona. Si tienes un problema técnico en mente, escribe qué es en una frase. Para mí vale más que un currículum.