En CodeGPT celebramos llegar a 1.8 millones de descargas mientras el 23% de nuestros usuarios se iba por la puerta de atrás. Dashboard abierto, reunión de lunes. Los números de adquisición se veían hermosos. Hasta que alguien preguntó cuántos seguían usándolo después de un mes.
Nadie sabía. Ni yo. Porque nunca habíamos pensado en preguntar. Estábamos demasiado ocupados celebrando.
Fui a revisar. Lo que encontré me quitó el sueño: perdíamos el 23% de nuestros usuarios cada mes. No era un ataque, no era un bug, no era la competencia. Éramos nosotros. Estábamos llenando un balde con un agujero en el fondo.
Este artículo es el post-mortem que nunca pensé publicar. Exactamente qué estábamos haciendo mal, cómo lo diagnosticamos, y el framework paso a paso que implementamos para revertirlo.
Tabla de contenido
- El contexto: por qué el churn nos estaba matando
- El error: optimizamos la métrica equivocada
- El diagnóstico: cómo identificamos el problema real
- El framework que implementamos
- Los resultados: antes y después
- Preguntas frecuentes
El contexto: por qué el churn nos estaba matando
CodeGPT es una extensión de VS Code para asistencia con IA. 1.8 millones de descargas, reviews de 5 estrellas. El producto era bueno. Esa no era la discusión.
El problema era la paradoja que nadie quiere enfrentar: más descargas no significa más revenue. Sobre todo en freemium.
El modelo es simple: versión gratuita limitada, versión de pago con features avanzados. El objetivo es que el usuario pruebe gratis, experimente el valor, y eventualmente pague. Pero el freemium amplifica el problema de retención de una manera brutal: cada usuario que se va sin pagar representa CAC desperdiciado y word-of-mouth negativo potencial. Un developer que instala tu extensión, no logra configurarla, y la desinstala frustrado, no va a recomendarte. Probablemente hable mal de ti en Twitter.
El churn mensual promedio en B2B SaaS es 3.5%. Nosotros estábamos en 23%. Casi 7 veces peor que el benchmark.
Y aquí está el dato que debería quitarte el sueño: adquirir un cliente nuevo cuesta significativamente más que retener uno existente. El rango varía según el estudio (de 5x a 25x dependiendo de la industria), pero el principio es consistente. Cada usuario que churneaba no solo era MRR perdido. Era todo el dinero que gastamos en traerlo, más la oportunidad de que ese dinero hubiera ido a usuarios que sí se quedaban.
Los developers son early adopters, pero también early abandoners. Prueban todo, tienen poca paciencia. Si tu producto no les entrega valor inmediato, lo desinstalan y pasan al siguiente. No hay segunda oportunidad.
El error: optimizamos la métrica equivocada
Nos enamoramos de las métricas de vanidad.
Descargas. Instalaciones. Usuarios registrados. Fáciles de medir, fáciles de celebrar, fáciles de presentar en reuniones. "Llegamos a 1.8 millones de descargas" suena mejor que "el 77% de nuestros usuarios no vuelve después del día 30".
Invertíamos el 80% del esfuerzo en adquisición y solo el 20% en activación y retención. Marketing optimizaba para traer usuarios. Producto optimizaba para agregar features. Nadie optimizaba para que los usuarios que llegaban realmente usaran el producto.
Primer error: confundimos instalación con adopción. Una instalación de extensión de VS Code toma dos clics. Pero eso no significa que el usuario haya configurado su API key, probado una feature, o integrado CodeGPT en su workflow diario. Significa que hizo dos clics. Eso es todo.
Segundo error: el funnel invertido. Gastábamos en campañas de Product Hunt, Reddit ads, contenido en Twitter. Funcionaba. Llegaban. Pero se encontraban con un onboarding de seis pasos: instalar, crear cuenta, obtener API key de OpenAI, copiarla en settings, configurar modelo, probar primer prompt.
Seis oportunidades de abandono. Muchos se iban antes de ver un solo resultado. Nunca llegaban a experimentar el valor porque abandonaban en la configuración.
Tercer error: métricas que nos mentían. El dashboard mostraba "usuarios activos mensuales" que incluía a cualquiera que abriera VS Code con la extensión instalada. Pero la métrica que correlacionaba con retención y revenue era "usuarios que completaron al menos 10 prompts en la semana". Esa era 15 veces menor.
Los reviews negativos en el marketplace los leía Support, no Product. Los usuarios que desinstalaban no dejaban feedback. Solo veíamos lo que queríamos ver porque lo otro estaba en canales que no monitoreábamos.
Según estudios de onboarding, mejorar la experiencia de onboarding puede aumentar la retención hasta un 25%. Nosotros teníamos un onboarding que mataba usuarios antes de que probaran el producto.
El diagnóstico: cómo identificamos el problema real
Jueves, revisión de métricas. Alguien puso los datos de retención por cohorte en pantalla grande. La curva caía como piedra.
Día 1: 100% de usuarios. Día 7: 45%. Día 30: 31%. De cada 100 usuarios que instalaban CodeGPT, solo 31 seguían usándolo un mes después.
Y el peor dato: el 60% de los usuarios que churneaban nunca habían completado el onboarding. Se iban antes de experimentar ningún valor.
Ese fue el click. No teníamos un problema de producto. Teníamos un problema de Time to Value.
Para confirmar, implementamos tres cosas: cohortes de retención en Mixpanel, un Cancellation Capture System con formulario de cinco opciones más campo abierto, y encuestas in-app para usuarios activos.
Growth MarketingTodo lo que publico aquí es gratis. Implementarlo contigo tiene precio.
Si algo de lo que leíste te hizo pensar "esto me está pasando", hablemos. Te respondo el mismo día.
Agendar 30 min →Las cinco razones principales de cancelación:
"Nunca logré configurarlo" (32%). El onboarding técnico era demasiado complejo. Conseguir una API key, configurarla, elegir modelo. Muchos no tenían la paciencia.
"No entendí cómo usarlo en mi workflow" (24%). CodeGPT tiene features poderosas. Pero los usuarios no sabían cuándo usar qué. Probaban una cosa, no veían cómo encajaba en su trabajo, abandonaban.
"El precio no justifica el valor" (18%). Completaron onboarding pero no experimentaron suficiente valor antes del cobro.
"Encontré otra herramienta" (15%). GitHub Copilot, Cursor, alternativas. El mercado de IA para developers es competitivo.
"Problemas de pago" (11%). Churn involuntario. Tarjetas vencidas, errores de procesamiento.
El 56% del churn era por experiencia de onboarding y adopción. No era el producto. Era cómo lo presentábamos.
Y había correlación directa: usuarios que completaban su primer prompt en menos de 10 minutos tenían 4 veces mejor retención a 30 días que usuarios que tardaban más de 24 horas.
El framework que implementamos
Este es el sistema exacto que implementamos. No es teoría. Es lo que funcionó.
Paso 1: Mata los pasos antes del primer prompt
El problema: Configurar CodeGPT requería cinco pasos con múltiples puntos de abandono.
La solución:
Implementamos un "modo demo" con 50 créditos gratuitos. El usuario podía probar inmediatamente sin configurar ninguna API key. Primero que experimente el valor, después que configure su setup permanente.
Agregamos un wizard in-app que guiaba los primeros tres prompts. En lugar de dejar al usuario frente a un editor vacío, le mostrábamos ejemplos: "Selecciona este código y presiona Cmd+Shift+E para que te lo explique".
Cambiamos la métrica principal de onboarding. Ya no era "usuarios que crearon cuenta". Era "tiempo hasta primer prompt exitoso".
El resultado: 67% de nuevos usuarios completaban su primer prompt, versus 23% antes. Medido en cohortes semanales durante 8 semanas post-implementación, baseline de 3 meses anteriores.
Paso 2: Muestra las 3 features que retienen
El problema: Los usuarios que configuraban CodeGPT solo usaban "completar código". No descubrían que podía explicar código, generar tests, o crear documentación.
La solución:
Identificamos las tres features con mayor correlación a retención: "explicar código", "generar docstrings", "crear tests". Esas se convirtieron en nuestras features target.
Implementamos "feature discovery" contextual. Cuando el usuario seleccionaba código, aparecía un tooltip: "Puedes explicar este código con Cmd+Shift+E". El producto enseñaba a usarse en el momento relevante.
Creamos una secuencia de emails de onboarding con casos de uso específicos. Día 1: explicar código. Día 3: generar documentación. Día 5: crear tests. Cada email con caso de uso concreto y ejemplo visual.
El resultado: Usuarios que usaban 3+ features tenían 4 veces mejor retención a 30 días. El porcentaje que llegaba a usar 3+ features subió de 12% a 38%.
Paso 3: Recuérdales cuántas horas les ahorraste
El problema: Usuarios que pasaban la primera semana activos desaparecían en la semana 3 o 4. El "novelty effect" se acababa y no había razón para volver.
La solución:
Implementamos un weekly digest por email. "Esta semana usaste CodeGPT para 47 prompts. Ahorraste aproximadamente 3 horas de trabajo." Datos concretos que recordaban el valor.
Comunicamos nuevas features in-app, no solo por email. Los usuarios que vivían dentro de VS Code no leían emails, pero sí veían notificaciones en su editor.
Creamos comunidad en Discord con canales por caso de uso. No solo soporte técnico. Canales donde developers compartían cómo usaban CodeGPT. Los usuarios activos ayudaban a los nuevos.
El resultado: La retención de semana 4 subió de 31% a 52%.
Paso 4: Atrapa al usuario antes de que decida irse
El problema: Cuando un usuario dejaba de usar CodeGPT, nos enterábamos cuando cancelaba. Para entonces ya era tarde.
La solución:
Implementamos scoring de riesgo de churn. Variables: días desde último uso, reducción de prompts por semana, features abandonadas. Score actualizado diariamente.
Configuramos triggers automáticos cuando el score subía. Email personalizado preguntando si todo estaba bien. Oferta de llamada de soporte. Descuento temporal.
Para churn involuntario, implementamos dunning agresivo. Cuatro intentos de cobro espaciados. Emails explicando el problema con la tarjeta. SMS como último recurso.
El resultado: Recuperamos 34% de usuarios "en riesgo" antes de que cancelaran. El churn involuntario bajó de 11% a 3%.
Los resultados: antes y después
Números reales. Sin maquillaje.
| Métrica | Antes | Después | Cambio |
|---|---|---|---|
| Churn mensual | 23% | 8% | -65% |
| Retención D30 | 31% | 52% | +68% |
| Tiempo a primer prompt | 4.2 días | 8 min | -99.87% |
| Onboarding completado | 23% | 67% | +191% |
| NRR | 72% | 94% | +31% |
Con el mismo gasto en adquisición, el MRR se multiplicó por 5 en menos de un año. No gastamos más en ads. No contratamos más gente. Simplemente dejamos de perder a los usuarios que ya estábamos trayendo.
El LTV promedio subió de $47 a $156. El ratio LTV:CAC pasó de 1.8:1 a 5.2:1.
Para contexto: el Net Revenue Retention top-tier está por encima del 120%. Llegamos a 94%, respetable. La meta de churn anual saludable es menor al 5%. Nuestro 8% mensual todavía era alto, pero venía del 23%.
Lo que NO cambió: El producto core. Las features principales. El equipo. El presupuesto de marketing.
Lo que SÍ cambió: Dónde poníamos la atención. Cómo medíamos el éxito. La experiencia de los primeros siete días.
Tres cambios de enfoque que multiplicaron el negocio por 5.
Preguntas frecuentes
Qué herramientas usaron para medir retención
Mixpanel para cohortes, Stripe para churn de pagos, y un scoring interno de riesgo. No necesitas herramientas caras, necesitas disciplina para revisar los números cada semana.
Cuánto tiempo tomó ver resultados
Métricas de onboarding mejoraron en dos semanas. Retención a 30 días tardó un mes en moverse. Impacto en MRR notable después de tres meses.
Esto aplica solo para developer tools
El framework es agnóstico al vertical. Lo que cambia es la definición de "Aha moment". Para nosotros era "primer prompt exitoso". Para un CRM podría ser "primera deal creada". El principio es el mismo.
Cómo priorizaron retención versus adquisición
No es trade-off. Cambiamos el ratio de inversión de tiempo de 80-20 a 50-50. La retención es un multiplicador de la adquisición. Con 8% de churn, cada usuario nuevo vale más porque se queda.
Qué hicieron con usuarios que ya habían churneado
Campaña de win-back para churneados en los últimos 90 días. Acceso gratuito 14 días más onboarding personalizado. Recuperamos 12% con mejor retención que usuarios nuevos.
Si tu dashboard muestra crecimiento mientras tu MRR dice otra cosa, el problema no es el producto. Es el sistema. Retención no es trabajo de soporte. Retención ES el negocio.
Si tu balde tiene un agujero, no importa cuánta agua eches. Tapa el agujero primero.
Growth marketing no es solo adquisición. Es hacer que usuarios lleguen, experimenten valor, y se queden. Si quieres ayuda construyendo un sistema que funcione, hablemos.
© 2026 Andres Ospina
