RS Systems es la práctica de ingeniería de un desarrollador full-stack autodidacta que trabaja con Python y Node/TypeScript. Construyo los backends, las API y la automatización que conectan las herramientas de una empresa, y los mantengo funcionando en producción en Linux.

El trabajo suele ser así. Una empresa tiene datos repartidos en un sitio web, una hoja de cálculo, un CRM y una bandeja de entrada, y alguien los está copiando a mano. Yo escribo el servicio que elimina la copia: un backend FastAPI o Express con una superficie REST limpia, trabajos programados que extraen los datos, validación y deduplicación para que el mismo registro nunca llegue dos veces, y un paso de entrega (base de datos, hoja, webhook) que el resto del equipo ya entiende.

El scraping y la integración son las habilidades principales. Utilizo Playwright y el Protocolo de Herramientas para Desarrolladores de Chrome para páginas que envían sus datos en JavaScript, los analizo en registros tipados y los enriquezco cuando la fuente está incompleta. Cuando existe una API pero es incómoda, con peculiaridades de paginación, puntos finales no documentados o autenticación frágil, la mapeo una vez y la envuelvo para que deje de ser frágil.

También trabajo por debajo de la capa de aplicación. Unidades y temporizadores de systemd, supervisión de registros y procesos, Docker, implementación y monitoreo, y lectura de un seguimiento de pila hasta que se muestre la causa real. Esa suele ser la diferencia entre una demostración y algo en lo que una empresa puede confiar.

Mi propia pila es la misma ingeniería a escala: una plataforma de cuatro agentes que funciona sin supervisión en systemd con watchdogs y un interruptor de apagado de una sola tecla, un enrutador LLM de múltiples proveedores con conmutación por error clasificada, un compactador de definición de herramientas que expone más de mil herramientas a través de un índice de búsqueda, y un arnés de navegador que pone una sesión de chat web detrás de una API compatible con OpenAI. Cuarenta repositorios públicos, la mayoría de ellos construidos para resolver un problema que realmente tuve.

Trabajo con un alcance fijo y un plan escrito antes de codificar, hitos que se pueden probar, pruebas y documentación incluidas, y una entrega que no me requiere. La entrega típica es de tres a catorce días. Estoy en la hora del este de EE. UU. y disponible treinta o más horas a la semana.

Envíame el flujo de trabajo que sigue fallando y te responderé con un plan y un precio.