Sprint zero features: 30 commits de pulido antes del lanzamiento

El pulido es más rentable que las características. En 48 horas y 30 commits sin ninguna característica nueva, hice mi aplicación más sólida que en seis meses de adiciones. Aquí te explico por qué un sprint de "cero características" antes de un lanzamiento es la mejor decisión que un desarrollador solitario puede tomar.

¿Por qué hacer un sprint sin características antes del lanzamiento?

Durante seis meses, cada día de desarrollo añadía algo. Una característica, una pantalla, un pipeline, una integración. El contador de commits subía, los archivos se apilaban, y la aplicación crecía a lo largo de los más de 650 commits.

Y luego llega un momento en que hay que parar. No por cansancio, sino por lucidez. La aplicación funciona para 12 probadores alfa que conocen sus límites. Pero el público en general no perdona. Según un estudio de Apptentive, el 77% de los usuarios leen al menos una reseña antes de descargar una aplicación. Y un solo error visible en el momento equivocado es una reseña de 1 estrella.

Esta semana, hice lo contrario de todo lo que había hecho hasta ahora: 30 commits en 48 horas. Cero características. Solo pulido, correcciones y preparación para el momento en que la aplicación sale de la fase alfa y entra en el mundo real.

¿Cómo corregir 15 errores en una sola pantalla de personalización de IA?

La IA de TAMSIV permite a los usuarios presentarse por voz. Tú presionas, cuentas tu vida en 30 segundos, y el asistente se adapta a tu personalidad. El problema: la pantalla de configuración tenía 15 errores sutiles que las pruebas automáticas no detectaban.

Un botón oculto por una superposición. Un texto truncado en pantallas pequeñas. Un bucle infinito cuando el usuario interrumpía la IA en medio de una respuesta. El prompt que se reiniciaba después de cada modificación. Los botones de acción apilados uno encima del otro en lugar de colocarse verticalmente.

Ninguno de estos errores se habría encontrado en una prueba rápida. Era necesario usar la aplicación como un usuario real: presionar en todas partes, interrumpir en el momento equivocado, retroceder, volver a intentarlo. Esto es lo que el Nielsen Norman Group llama prueba de usabilidad exploratoria: sin guion, solo un humano que intenta romper la interfaz.

15 commits para hacer que una sola pantalla sea confiable. Parece excesivo. Pero cuando es la pantalla la que define cómo te entiende la IA, cada micro-error degrada toda la experiencia.

¿Cuál es la diferencia entre "funciona en alfa" y "está listo para producción"?

El sistema de suscripciones Free/Pro/Team existía desde febrero. Funcionaba en alfa. Pero "funcionar en alfa" y "estar listo para producción" son dos cosas muy diferentes.

En alfa, 12 probadores saben que es un trabajo en progreso. Aceptan una redacción aproximada, un diseño no del todo definido, límites difusos entre los planes. En producción, cada ambigüedad cuesta un usuario. Según ProfitWell, una página de precios confusa puede reducir las conversiones entre un 20 y un 40%.

La revisión tocó tres ejes:

• La redacción: cada texto fue revisado para aclarar qué es gratuito y qué es de pago. No más formulaciones ambiguas.
• El diseño del modal alfa: ya no tiene razón de existir en producción. Eliminado y reemplazado por un flujo natural hacia los planes de RevenueCat.
• Los límites del plan gratuito: cada pantalla verificada en 3 tamaños de pantalla diferentes, cada texto responsivo.

El tipo de trabajo que no se ve en un changelog, pero que marca la diferencia entre un usuario que entiende lo que paga y un usuario que desinstala por confusión.

¿Qué "pequeños detalles" tienen el mayor impacto en la retención?

Tres ajustes menores transformaron la experiencia diaria de la aplicación.

El botón de detener TTS. Cuando la IA te responde en voz alta y quieres detenerla, antes tenías que silenciar el teléfono. Ahora un interruptor es suficiente. Parece trivial, pero es exactamente el tipo de fricción que empuja a un usuario a desinstalar. El dictáfono es el corazón de TAMSIV, debe ser impecable.

El alcance estricto del LLM. La IA tendía a responder preguntas fuera de tema: clima, cultura general, filosofía. En producción, debe permanecer concentrada: tareas, notas, eventos. Punto. Una salvaguarda de backend que rechaza educadamente todo lo demás. Como explica la guía de ingeniería de prompts de OpenAI, definir límites claros para el LLM es esencial para una experiencia de usuario coherente.

El interruptor de imágenes generadas. Cada conversación puede generar una imagen de portada a través de IA, gracias a la integración de Runware en el dictáfono. Pero eso cuesta créditos. Un interruptor en el encabezado del dictáfono ahora permite desactivar la generación de imágenes sobre la marcha. Transparencia y control.

¿Qué representa el versionCode 30 para un desarrollador solitario?

Cada compilación de Android tiene un número. Estamos en la 30. Las 29 anteriores eran alfa, compilaciones para 12 probadores que aceptaban errores a cambio de la primicia. La compilación 30 es la última antes de que cualquiera pueda descargar TAMSIV en Play Store.

Es un número trivial. Pero representa el momento en que "mi aplicación" se convierte en "una aplicación". Donde el código ya no está protegido por el filtro benevolente de los beta-testers. Donde cada error es una posible reseña de 1 estrella.

Para poner esto en perspectiva: el sprint de calidad anterior ya había corregido docenas de problemas. La compilación 30 es la culminación de dos semanas de pulido intensivo, no solo de 48 horas. Es la capa final antes de la puesta en producción.

¿Cómo decidir cuándo dejar de añadir características?

La tentación del desarrollador solitario es añadir siempre más. Una característica llama a otra. El backlog nunca se vacía. Y cuanto más crece la aplicación, más cada adición crea interacciones imprevistas con el resto.

Apliqué una regla simple: si un error puede encontrarse en los primeros 5 minutos de uso, tiene prioridad sobre cualquier característica del backlog. Esto es lo que Marty Cagan llama la "prueba del cliente de referencia": si tu usuario de referencia no puede completar el recorrido básico sin fricción, nada más importa.

Este sprint me enseñó algo: el pulido no es el enemigo del progreso. Es lo contrario. Corregir 15 errores en una sola pantalla hizo que la aplicación fuera más sólida que cualquier característica nueva. Los usuarios no ven los commits. Ven una aplicación que funciona, o que no funciona.

¿Cuál es el flujo de trabajo de un sprint de pulido en la práctica?

Concretamente, así organicé estas 48 horas:

1. Auditoría por pantalla: abrí cada pantalla de la aplicación en 3 dispositivos diferentes (pequeño, mediano, grande) y anoté cada anomalía visual o funcional.
2. Priorización por impacto: los errores visibles en los primeros 5 minutos arriba, los casos extremos abajo.
3. Commits atómicos: un commit = una corrección. No hay commits de todo un poco. Esto permite revertir quirúrgicamente si una corrección rompe otra cosa.
4. Prueba de regresión: después de cada corrección, se vuelven a verificar las pantallas adyacentes. Cuando tocas la arquitectura de un componente compartido, el efecto dominó es real.

Este flujo de trabajo no es espectacular. No hay nueva tecnología, no hay refactorización heroica. Solo disciplina y tiempo dedicado a usar la propia aplicación como un usuario común.

¿Por qué el pulido es más rentable que las características para un lanzamiento?

Las cifras son claras. En Play Store, las aplicaciones con una calificación inferior a 4 estrellas pierden hasta el 50% de sus descargas potenciales. Y las primeras reseñas son decisivas: definen la trayectoria de la aplicación durante los meses siguientes.

Añadir una característica que impresiona al 10% de los usuarios pero que crea un error para el 5% de ellos es un mal intercambio. En cambio, corregir 30 micro-errores que potencialmente afectan a todos es una inversión con un rendimiento garantizado.

Este sprint de pulido afectó a todo el recorrido del usuario: desde el onboarding hasta la gestión de suscripciones, pasando por el corazón de la aplicación: el dictáfono de voz. Y la diferencia se juega en estos 30 commits invisibles.

La compilación 30 está lista. La aplicación es más limpia, más estable, más clara de lo que nunca ha sido. Lo que sigue es el público en general.