Cómo crear una página de changelog sin programar en 2026

Para crear una página de changelog sin programar, describe la estructura de una entrada (fecha, versión, tipo de cambio y texto) y deja que un constructor con IA genere la página con las primeras entradas dentro. En Zugo esa primera versión se construye en alrededor de un minuto y se publica en un clic en tu propia dirección.

Un changelog parece la página más simple de un producto y es la que más veces se abandona. Se publica con tres entradas, se deja de actualizar en marzo y acaba comunicando lo contrario de lo que pretendía. Esta guía va sobre construirla y, sobre todo, sobre que siga viva.

¿Qué información lleva una entrada de changelog?

Una entrada útil responde a tres preguntas de un vistazo: cuándo cambió, qué cambió y si le afecta a quien lee. Todo lo demás es decoración. Define esos campos antes de escribir el prompt, porque son los que fijan el diseño.

Fecha y versión. La fecha es obligatoria y visible. El número de versión es opcional: si tu producto es web y despliegas a diario, la fecha ya identifica el cambio mejor que un número.

Tipo de cambio. Tres etiquetas bastan para casi todo: Nuevo, Mejora y Arreglo. Añadir una cuarta, Cambio importante, tiene sentido si tienes API pública, porque es la que la gente busca de verdad.

Título en lenguaje de usuario. "Ahora puedes exportar la lista en CSV" se entiende. "Refactor del módulo de exportación" no dice nada a quien paga.

Detalle corto y opcional. Dos o tres frases sobre qué resuelve y dónde encontrarlo. Una captura si el cambio es visual.

Un prompt que ya trae toda esa estructura:

Página de changelog para [producto], un [qué es].
Cada entrada: fecha, etiqueta (Nuevo / Mejora / Arreglo /
Cambio importante), título en lenguaje de usuario y detalle corto.
Orden: la más reciente arriba, agrupadas por mes.
Filtro por etiqueta en la parte superior.
Cabecera con el nombre del producto y enlace de vuelta a la app.
Incluye estas [N] entradas reales: [pega aquí tus últimos cambios].
Tono: directo, sin superlativos, en primera persona del plural.

Pegar entradas reales en el prompt cambia mucho el resultado. Con contenido de verdad el constructor decide bien la jerarquía tipográfica y el espaciado, en lugar de maquetar sobre texto de relleno que luego no se parece a lo tuyo.

¿Qué diferencia hay entre un changelog, unas notas de versión y un blog?

Se confunden a menudo y sirven a lectores distintos. Elegir mal el formato hace que un mismo esfuerzo rinda la mitad.

La regla práctica: el changelog es el registro completo y el blog es la selección. Un lanzamiento importante vive en los dos sitios, con el changelog enlazando al artículo largo.

¿Cómo se añade una entrada nueva cada semana?

Aquí se decide si la página sigue viva a los seis meses. Hay dos caminos y conviene elegir a conciencia.

El camino corto es pedir la entrada por chat: "añade una entrada del 12 de agosto, etiqueta Mejora, título 'Los filtros ahora se guardan al recargar', con dos frases de detalle". Cada edición cuesta 3 créditos y tarda menos que escribir el mensaje. Funciona bien si publicas una o dos veces al mes.

El camino largo es conectar Supabase y guardar las entradas en una tabla. La página lee de ahí, y añadir un cambio pasa a ser una fila nueva en lugar de una construcción. Sale a cuenta en cuanto publicas cada semana, y además te deja escribir desde un formulario interno en vez de desde el chat del constructor.

La segunda opción convierte el changelog en una pequeña aplicación con datos, no en una página estática. Si ese es el camino, el planteamiento general está en cómo crear una app sin programar, y el patrón de tabla más formulario es el mismo que en cómo crear un CRM sin programar.

¿Cómo se entera la gente de que hay entradas nuevas?

Una página que nadie visita dos veces no cumple su función. Tres mecanismos cubren casi todos los casos y ninguno necesita programar.

Un enlace dentro del producto. El sitio más eficaz es un enlace discreto en el menú de la aplicación, con un punto de color cuando hay algo sin leer. Sin esto, el resto rinde poco.

Correo con Resend. Un aviso mensual con los cinco o seis cambios que más importan, no uno por entrada. El conector de Resend envía desde tu dominio y el resumen se escribe a mano en diez minutos.

Analítica con Google Analytics. Sirve para una decisión concreta: si nadie abre la página desde el producto, el problema es el enlace y no el contenido.

Lo que no conviene es prometer notificaciones automáticas por correo en cada despliegue. Eso es una integración con tu sistema de publicación, y es trabajo de programador aunque la página sea generada.

¿Cuánto cuesta y qué se publica exactamente?

El plan gratuito da 5 créditos para probar. Pro cuesta $25 al mes con 200 créditos e incluye conectar tu dominio propio, que en un changelog importa porque suele vivir en un subdominio de la marca. Business cuesta $99 al mes.

Una construcción cuesta 6 créditos y cada edición cuesta 3. Si el changelog crece hasta tener secciones separadas por producto, entra en territorio de plataforma: 12 créditos por las tres primeras páginas y 3 créditos por cada página adicional. El modo Hi-Fi cuesta el doble: 12 la construcción y 6 la edición.

Antes de entregarse, la construcción se arranca en un sandbox y tiene que cargar. Una construcción que no abre se reporta como fallida en lugar de llegarte como pantalla en blanco. Es una red de seguridad, no una garantía: revisa el filtro por etiqueta y las fechas antes de enlazar la página desde tu producto.

¿Dónde está el límite de este enfoque?

Tres casos en los que un changelog generado se queda corto, dichos sin rodeos.

Generación automática desde commits. Si quieres que la página se escriba sola leyendo los mensajes de tus commits o tus pull requests, eso es una tubería entre tu repositorio y el sitio. Se puede montar, pero la monta un programador con la exportación a GitHub en la mano, no un prompt.

Changelogs versionados por API. Documentación con varias versiones vivas, avisos de retirada y enlaces a guías de migración es documentación técnica, y las herramientas hechas para eso ganan.

Volumen alto con muchos autores. Si diez personas publican entradas a la semana, necesitas permisos, revisión y un flujo editorial. Ahí el enfoque correcto es la tabla en Supabase con roles, y sigue siendo un producto que se diseña, no que se describe en una frase.

Para el caso normal, un producto pequeño que quiere enseñar que se mueve, la página se construye en una tarde y el trabajo de verdad empieza al día siguiente: escribir una entrada cada vez que algo cambie. Si además vas a montar un espacio donde tus usuarios hablen entre ellos, el método continúa en cómo crear un sitio de comunidad. Empieza por describir tu changelog en zugo.dev.