Durante mis prácticas en Entreredes desarrollé de forma autónoma AutoLanding, una herramienta interna de la empresa. El código y la herramienta pertenecen a Entreredes, así que aquí no hay código ni capturas: cuento qué hacía, cómo estaba construida y qué aprendí.
Qué resolvía
Preparar una propuesta para un negocio local llevaba horas: buscar sus datos, escribir los textos, conseguir imágenes y maquetar la página. AutoLanding lo automatizaba: a partir de un negocio, generaba una landing page completa lista para enseñar al cliente.
Un flujo de trabajos encadenados
Al crear un lead se encadenaban tres trabajos en cola: extraer los datos del negocio de Google Places (dirección, teléfono, reseñas y fotos), generar los textos por secciones con Gemini, adaptados al sector, y resolver las imágenes, combinando fotos reales con imágenes generadas. El resultado se revisaba en una vista previa, se compartía con el cliente mediante un enlace firmado y caducable, y se podía exportar.
Todo se gestionaba desde un panel en Filament, con 14 sectores de negocio con estilos propios e importación y exportación de leads en Excel.
Las tareas pesadas, siempre en colas
Las llamadas a Google y a Gemini tardan y pueden fallar, así que nunca se hacían durante la petición del usuario: iban en colas con Redis, procesadas por un worker aparte, con un programador para las tareas periódicas. La interfaz respondía siempre, aunque una generación tardara.
Seguridad desde el principio
La aplicación recibía datos externos y los enviaba a un modelo de IA, así que la seguridad no podía dejarse para el final: limitación de peticiones en los endpoints sensibles, saneado del texto que llega al modelo contra inyección de prompts, validación del destino de las descargas para evitar SSRF, enlaces firmados con HMAC, neutralización de fórmulas en los CSV exportados y cabeceras CSP y HSTS.
225 tests antes de cada despliegue
Con PHPUnit, incluidos tests de rotura que intentan tumbar la aplicación con entradas maliciosas o inesperadas, pruebas de carga y fuzzing, y una verificación del flujo completo con las APIs simuladas o reales. Ningún despliegue salía sin pasarlos.
En producción con Docker
Se desplegó en el servidor de la empresa con Docker Compose: la aplicación, MySQL, Redis, el worker de colas y el programador, cada uno en su contenedor, detrás de un proxy con SSL automático.
Lo que aprendí: diseñar para el fallo
Fue la primera vez que un proyecto entero dependía de mí: diseñarlo, probarlo, desplegarlo y responder cuando algo fallaba. Aprendí a tratar cada API externa como algo que va a fallar y a diseñar para ello, y que los tests de rotura encuentran lo que los tests normales no ven. Lo que construyo hoy, como leo-mcp, parte de esa forma de trabajar.