About this case study
Esta guía describe un proceso repetible de marketing de lanzamientos, no un resultado reportado por un cliente ni la promesa de que una actualización concreta hará volver a usuarios inactivos.
Cada lanzamiento es contenido que ya has pagado
En 2026 el desarrollo casi nunca es el cuello de botella. Con Lovable, Bolt, Cursor, v0 o Replit puedes lanzar tres o cuatro mejoras reales en una semana. Lo que casi nadie hace es contarlo. El trabajo entra en producción, el historial de Git crece y solo se enteran quienes ya tienen la aplicación abierta.
Un changelog es el contenido más barato que escribirás nunca, porque el pensamiento ya estaba hecho antes de abrir el editor. No estás inventando un tema: estás informando de uno. La única decisión que queda es si lo escribes como un diff o como un resultado.
Un diff dice: «Añadida la exportación masiva a CSV». Un resultado dice: «Ahora puedes llevar un mes de datos a una hoja de cálculo con un clic, así que el informe del cliente deja de ser un ejercicio de reescritura». El mismo lanzamiento, un lector completamente distinto. La primera frase está escrita para ti. La segunda está escrita para alguien que está decidiendo si vale la pena volver a abrir tu aplicación.
Escrito en forma de resultados, un changelog hace dos cosas a la vez. Llega al usuario que se fue precisamente porque faltaba lo que ahora existe. Y le enseña a quien llega por primera vez algo que ninguna landing page puede fingir: un producto que se mueve de forma visible.
La plantilla de entrada del changelog
Cada entrada responde a las mismas preguntas en el mismo orden. Cuatro líneas cortas, una captura, un enlace:
- Qué ha cambiado, en una frase que entienda alguien de fuera del código. Sin nombres internos, sin números de ticket, sin «hemos refactorizado la capa de sincronización».
- Para quién es, descrito como un comportamiento y no como un plan de suscripción: «si revisas publicaciones desde el móvil», «si gestionas más de una marca».
- Qué puede hacer ahora esa persona y no podía la semana pasada. Esta es la línea que consigue el clic, así que escribe una capacidad y no el nombre de una funcionalidad.
- Por qué importa, en una oración: la molestia que desaparece, el paso que se elimina, el apaño que se jubila.
- Una captura o un clip corto de la cosa en sí, recortado justo sobre el cambio. Una imagen del nuevo estado vale más que cualquier adjetivo que le pongas al lado.
- Un enlace, directo a la pantalla donde vive el cambio. No a la página de inicio: nadie va a ponerse a buscar.
Qué lanzamientos merecen una publicación pública
No todos. Si cada actualización de dependencias se convierte en anuncio, tu audiencia aprende que tus publicaciones se pueden saltar sin riesgo, y el único lanzamiento que importaba se salta junto con el resto. Es la contención lo que mantiene el canal digno de leerse.
La regla es lo bastante estrecha como para aplicarla en cinco segundos: un lanzamiento merece publicación cuando cambia lo que alguien puede hacer, elimina un motivo declarado por el que alguien se fue o se ve en cuanto se abre la aplicación. Todo lo demás —correcciones, rendimiento, ajustes de texto— se queda en la página del changelog pero no recibe publicación propia.
Para quien lanza cada semana, esto suele asentarse en un reparto sencillo. Todo entra en la entrada del changelog. Aproximadamente un lanzamiento por semana pasa el listón de la publicación pública. Una vez al mes, los pequeños se agrupan en un único resumen del tipo «lo que salió en agosto», para que el trabajo invisible también tenga su momento.
Si en una semana no pasa nada el listón, no fabriques un anuncio. Publica otra cosa: una decisión que revertiste, una limitación con la que chocaste, una duda en la que estás atascado. Es tu cadencia de build in public la que sostiene las semanas que la hoja de ruta no sostiene.
Convertir una entrada en una publicación por red
La entrada es la fuente. Cada red recibe la misma noticia con su propia forma, nunca el mismo bloque de texto pegado tres veces:
- Instagram: empieza por lo visual. La captura recortada o una grabación de pantalla de cinco segundos es la publicación; el pie dice para quién es y qué puede hacer ya esa persona.
- Threads: escríbelo en tono de conversación, como si se lo contaras a quien lo pidió. «Lo pedisteis. Ya está disponible». Después deja el hilo abierto y responde a lo que llegue.
- X: la versión más corta que se sostenga sola. Una línea sobre la capacidad, la captura, el enlace. Deja el razonamiento para una respuesta en lugar del primer mensaje.
- Mantén el mismo enlace de destino en las tres, para saber qué red llevó realmente gente a la pantalla nueva.
- Escribe las tres en la misma sesión, con el lanzamiento aún fresco. Volver a ello dos días después convierte el resultado otra vez en un diff, sin falta.
El flujo semanal, de principio a fin
Dale días fijos al ciclo para que sobreviva a una semana ocupada. Lanzar el miércoles. Escribir la entrada el jueves, mientras todavía recuerdas por qué construiste eso. Publicar el viernes por la mañana y dejar la tarde libre para responder a la gente. Cuatro huecos en el calendario y ninguna decisión que volver a tomar.
En Amplispect, la entrada entra una vez en el editor y pasa a ser la fuente de las tres versiones. La vista previa por red muestra cómo se verán realmente el texto y la captura en Instagram, Threads y X antes de que nada entre en cola, y la validación detecta el texto que supera el límite de una red o la imagen con el formato equivocado: los dos fallos que normalmente se descubren en directo.
Programa el conjunto en lugar de publicar a mano. Una publicación de lanzamiento que sale a la hora elegida es una publicación que preparas el jueves y para la que sigues disponible el viernes, algo que importa más que la hora exacta que escojas.
Después las respuestas vuelven a una sola cola en lugar de a tres aplicaciones. Amplispect sincroniza los comentarios compatibles en el espacio de trabajo y puede redactar una respuesta, pero nada sale sin que la hayas leído y aprobado. Responder en la primera hora a las primeras preguntas sobre una funcionalidad nueva es toda la razón de ser de ese viernes por la tarde libre.
Al cabo de un trimestre, repasa tus publicaciones de lanzamiento y pregúntate qué tipo de actualización generó respuestas de verdad. Los fundadores suelen llevarse una sorpresa: la pequeña molestia que desapareció supera a menudo a la funcionalidad estrella, porque más gente la había sufrido. Esa señal pertenece a la próxima hoja de ruta, no solo al próximo texto.
Lo que esto produce de forma realista
Tras un trimestre lanzando cada semana tienes alrededor de doce publicaciones de lanzamiento, una página de changelog que se lee como un producto con impulso y un registro de qué tipo de actualizaciones responde la gente de verdad. Ese registro es la parte valiosa: te dice qué anunciar a continuación y, a menudo, qué construir a continuación. Los usuarios que vuelven y los registros siguen siendo resultados que hay que medir, no cifras que este proceso pueda prometer.
La regla de seguridad
No anuncies nunca algo que no esté totalmente disponible para quien haga clic. Una publicación de lanzamiento que aterriza en un feature flag, en una lista de espera o en una pantalla que no se parece nada a la captura cuesta más confianza de la que la actualización devuelve. Lanza, captura lo lanzado y solo entonces publica.
Profundizar
Dónde encajan las publicaciones de lanzamiento en el resto de tu distribución:
- Convierte tu landing page en 30 días de publicacionesAprovecha las páginas que ya tienes para las semanas en las que no lanzas nada.
- Build in Public: una cadencia de publicación que trae usuarios, no solo seguidoresEl ritmo de publicación que sostiene las semanas entre lanzamientos.
- Tus primeras 10 publicaciones sobre tu app cuando aún no tienes usuarios ni testimoniosQué publicar antes de tener un changelog digno de anunciarse.
- Cómo hacer crecer tu app con un ciclo semanal de adquisiciónCómo un lanzamiento semanal se convierte en un ciclo de adquisición repetible.
- Cómo distribuir una app: la guía completa para fundadores que ya han construido algoLa visión completa de cómo poner una aplicación delante de la gente después de construirla.
- Programador de publicacionesEscribe el lanzamiento una vez, previsualízalo por red y programa todo el conjunto de una pasada.
- Gestión de comentariosReúne todas las respuestas a una publicación de lanzamiento en una cola que revisas antes de contestar.
Preguntas frecuentes
¿Qué debe incluir una entrada de changelog?
Qué ha cambiado en lenguaje sencillo, para quién es, qué puede hacer ya esa persona, por qué importa, una captura del cambio y un enlace a la pantalla exacta. Los números de versión y los nombres internos son opcionales; la capacidad no lo es.
¿Hay que publicar en redes sobre cada actualización?
No. Publica cuando un lanzamiento cambia lo que alguien puede hacer, elimina un motivo por el que alguien se fue o se ve nada más abrir la aplicación. Las correcciones y el trabajo de rendimiento se quedan en la página del changelog y pueden agruparse en un resumen mensual.
¿Cómo se anuncia una funcionalidad nueva en redes sociales?
Escribe primero el resultado y luego adáptalo a cada red: una publicación visual en Instagram, una conversacional en Threads y la versión más corta posible en X. Mantén el mismo enlace de destino en las tres para ver qué red trajo tráfico.
¿Las notas de versión funcionan de verdad como marketing?
Sí, cuando están escritas para los usuarios y no para el equipo. Son el único contenido cuyo trabajo ya está hecho, dan a los usuarios inactivos un motivo concreto para volver y demuestran a los visitantes nuevos que el producto sigue mejorando.