Paxl es un editor visual de landing pages. Montas la página con bloques, la ves en escritorio, tablet y móvil, la editas con otras personas a la vez y la publicas con su propia dirección. El frontend es Next.js con React y TypeScript, y el backend, Django con Channels para el tiempo real.
Un recorrido de 65 s por la aplicación real, de la sesión de invitado a la publicación. No tiene sonido y los rótulos del vídeo están en español.
01En corto
Qué hace.
Bloques con contenido tipado. Hay 15 tipos de bloque: hero, características, precios, preguntas frecuentes, galería, equipo, formulario de contacto… Los elementos de las listas se añaden, se quitan y se cambian de orden, y cada cambio se deshace en un solo paso.
Un tema para toda la página. Colores, tipografía, espaciado y bordes se definen una vez, con 14 paletas de partida, y en la página los colores del tema se ajustan solos para llegar al contraste AA.
Varias personas a la vez. Se ve quién está en la página, cada bloque se bloquea mientras alguien lo edita y los guardados se fusionan sin perder cambios. Publicar congela una copia: lo que editas no llega a los visitantes hasta que vuelves a publicar.
Plataforma
Aplicación web. El editor completo funciona en ordenador y en tablet, también con los dedos; en el móvil hay un editor rápido.
Django 5, Django REST Framework y Channels sobre Daphne. PostgreSQL para producción y SQLite en local; Redis es opcional.
Calendario
El primer commit es del 10 de marzo de 2026. En marzo y abril se hizo la base, en 5 commits; los otros 175 son del 8 al 11 de octubre.
Idiomas
Español e inglés, en la interfaz y en las plantillas. La interfaz tiene 1.109 textos en cada idioma.
02Mi papel
Quién hizo qué.
Yo
Decidí qué tenía que hacer Paxl.
Tomé las decisiones de producto que salieron al probarlo. Por ejemplo, que en la tablet se use el editor completo adaptado a los dedos y no el editor rápido del móvil.
Acepté que las páginas ya hechas cambiaran de aspecto cuando hiciera falta para llegar al contraste AA.
Lo que queda me toca a mí: subirlo a un alojamiento y hacer pública la demo.
Los agentes de Claude Code y Codex
Escribieron el código del frontend y del backend.
Escribieron las pruebas: más de 3.000 entre el backend, el frontend y las de punta a punta.
Llevaron el registro de decisiones (48 hasta ahora): el contexto, lo que se eligió y qué consecuencias tiene, y en muchas, lo que se descartó.
Documentaron 50 fallos notables: qué pasaba y el arreglo, y en la mayoría cómo se encontró y cómo se comprobó.
Trabajé con Claude Code y con Codex. Las reglas para los agentes están en el propio repositorio, y cada decisión y cada fallo importante quedan escritos. Así cada cambio se puede revisar por lo que hace y por cómo se comprobó.
03Cómo funciona
Cómo está hecho.
El navegador solo habla con Next.js. Next pasa a Django las llamadas a /api, así que las cookies de sesión son del mismo sitio y JavaScript nunca ve el token de sesión. El servidor manda: cada página tiene un número de versión, y todo lo que entra en un bloque, venga del editor, del WebSocket, de la IA o de una versión restaurada, pasa por la misma función de validación.
Navegador
EditorReact y Zustand
Visitanteabre la página publicada
/api con cookies httpOnly
Next.js
Reenvío de /apimismo sitio para las cookies
Página publicadagenerada en el servidor y en caché
REST · aviso al publicar
Django
API RESTDjango REST Framework
WebSocketChannels: presencia, bloqueos y avisos
Base de datosPostgreSQL o SQLite
IA, opcionaltu clave o el modo demo
El editor abre el WebSocket directamente con Django, con un ticket de un solo uso.
Por dónde pasa cada petición. Basado en el diagrama de arquitectura del README.
El WebSocket no lleva la página: solo avisa de que algo ha cambiado y retransmite lo que se escribe en el bloque bloqueado. La página publicada se genera en el servidor desde una copia congelada, y al publicar Django avisa a Next para que renueve la caché.
Tres problemas por el camino
Los tres tienen su entrada en el registro de decisiones del repositorio, con el contexto y lo que se descartó.
Colaboración · ADR-024
Dos personas guardando a la vez
Cada autoguardado mandaba la página entera y ganaba el último. Si una persona borraba un bloque y otra guardaba después, el bloque volvía.
Ahora cada página tiene una versión. Un guardado hecho sobre una versión vieja recibe un 409 con la página actual, y el editor fusiona en tres vías sin perder ninguna edición. Se probó con dos navegadores reales: 13 comprobaciones, tres pasadas seguidas sin un fallo.
IA · ADR-023
En modo demo, la IA no cuesta nada y lo dice
Una demo pública no puede gastar una clave de pago, y con una clave en el servidor cualquiera podía agotarla. En modo demo, que viene activado, Paxl no llama a ninguna IA: sirve una de diez páginas de ejemplo escritas a mano y lo dice en pantalla.
Con tu propia clave de Gemini o Anthropic genera de verdad, y la clave no se guarda. Lo que devuelve la IA pasa por la misma validación que el editor.
Publicar · ADR-017 y 019
Publicar congela una copia
Al principio la página pública leía los bloques en vivo, así que cada autoguardado cambiaba lo que veían los visitantes mientras aún se editaba. Ahora publicar guarda una copia, y nada llega al público hasta que vuelves a publicar.
La página pública se genera en el servidor y se queda en caché hasta la siguiente publicación. La prueba de esa caché encontró otro fallo: una página despublicada respondía 200 en lugar de 404.
04Calidad
Cómo se comprueba.
Hay más de 3.000 pruebas automáticas. GitHub Actions las ejecuta en cada push a main y en cada pull request, repartidas en cuatro trabajos, y el resultado de cada ejecución se puede ver en el repositorio.
Backend
1.887 pruebas con pytest, incluidas las del WebSocket. El CI las ejecuta con SQLite y con PostgreSQL 16.
Frontend
1.236 pruebas con Vitest, entre ellas pruebas de propiedades de la fusión con ediciones aleatorias. Además: tipos, lint y build.
De punta a punta
57 pruebas de Playwright en Chromium contra la aplicación real, con Daphne y next start: invitado, cuenta, publicación y colaboración entre dos navegadores.
El editor, con el bloque Hero seleccionado y sus campos en el inspector.
La vista Estilos: paletas, colores del tema y el aviso cuando un color no llega a AA.
La misma página en los marcos de tablet y móvil del editor.
En el móvil: el editor rápido, la hoja de un bloque y la página publicada.
El panel con las páginas, publicadas y en borrador.
Los mensajes que llegan desde el formulario de contacto.
Capturas de Paxl en local, con un asador inventado, Casa Tomillo, hecho con la plantilla de restaurante de Paxl. Las cuentas y los mensajes también son inventados. El vídeo es de un par de días antes y algunos detalles de la interfaz han cambiado.
06Estado
En qué punto está.
Paxl funciona en local y el código está en GitHub, con el CI en verde. Todavía no tiene demo pública: me falta subirlo a un alojamiento. Está pensado para un alojamiento gratuito con una sola instancia, y tiene límites conocidos:
Sin Redis, el tiempo real vive en la memoria de un solo proceso del servidor. Con Redis se comparten los bloqueos, pero la presencia sigue siendo de cada proceso.
En modo demo la IA no genera en vivo: sirve diez páginas escritas a mano. Para generar de verdad hace falta tu propia clave.
Sin un servidor de correo configurado, los enlaces para entrar por email no llegan a ningún buzón.
Los dominios propios están desactivados, y los pagos solo funcionan con una clave de prueba de Stripe.
El objetivo de accesibilidad es WCAG 2.2 AA y aún falta: algunos bordes del editor no llegan a 3:1, y el texto del lienzo solo se edita con doble clic (con teclado se edita desde el inspector).