Primer video de demostración y sprint de calidad: 7 correcciones críticas

Después de 6 meses de desarrollo y más de 700 commits, TAMSIV lo tenía todo: un pipeline de voz funcional, un sistema de gamificación, grupos colaborativos, 6 idiomas soportados. Pero faltaba algo esencial: un video. Porque una aplicación de voz no se describe. Se muestra. Esta semana, grabé el primer video de demostración de TAMSIV y, en paralelo, cerré un sprint de calidad que corrigió 7 problemas críticos.

Puntos clave a recordar:
- Un video de demostración es indispensable para una aplicación de voz: "habla y la IA entiende" no es suficiente, hay que ver el micrófono activarse y la tarea crearse.
- Un sprint de calidad (0 características, 7 correcciones) tiene tanto impacto como un mes de desarrollo cuando se enfoca en las fricciones diarias.
- El botón de parada de una grabadora de voz debe funcionar al 100%: incluso un 1% de fallo destruye la confianza.
- Siempre vaciar la caché singleton al cerrar sesión en un dispositivo compartido: una fuga de datos entre sesiones es un error de seguridad crítico.

¿Por qué un video de demostración es indispensable para una aplicación de voz?

Durante 6 meses, TAMSIV existió en texto y capturas de pantalla. En el sitio web, en los artículos del blog, en las fichas de Play Store. Pero una aplicación de voz tiene un problema fundamental de comunicación: la interacción principal es invisible.

Puedes escribir "habla, la IA entiende y organiza" tantas veces como quieras. Hasta que el visitante no haya visto el micrófono activarse, la transcripción en tiempo real, la tarea crearse sola en la carpeta correcta, no entenderá realmente lo que hace la aplicación.

Como explica Wyzowl en su informe de marketing de video de 2026, el 96% de los consumidores ven un video explicativo antes de comprar un producto o descargar una aplicación. Para una aplicación de voz, esta cifra es probablemente aún mayor: el concepto mismo requiere una demostración visual.

El video ahora es visible en YouTube y está directamente integrado en el hero del sitio tamsiv.com. El visitante ve inmediatamente cómo funciona TAMSIV, sin necesidad de descargar la aplicación ni de leer documentación.

¿Cómo integrar un video en el hero de un sitio Next.js?

La integración en el sitio Next.js era obvia, pero con algunas limitaciones técnicas:

• Rendimiento: sin reproducción automática, sin precarga del archivo de video completo. Un embed de YouTube con fachada (imagen de marcador de posición + botón de reproducción) para evitar cargar el iframe en el primer renderizado.
• Adaptable a móviles: la relación de aspecto 16:9 debe adaptarse sin barras negras ni desbordamientos en todas las pantallas.
• SEO: etiqueta VideoObject en JSON-LD para que Google indexe el video y lo muestre en los resultados enriquecidos.

El resultado: el hero del sitio ahora muestra una vista previa del video con un botón de reproducción. Un clic carga el embed de YouTube. Es el mejor compromiso entre impacto visual y rendimiento: el Largest Contentful Paint no se ve afectado.

¿Por qué un sprint de 0 características cambia todo para la retención?

Paralelamente al video, dediqué una semana a un sprint 100% de calidad. Ninguna nueva funcionalidad, solo pulido, fiabilidad y correcciones silenciosas que marcan la diferencia en el día a día. 7 commits. 0 nuevas características.

Esto es contraintuitivo cuando eres un desarrollador individual. Tienes una lista de características por añadir tan larga como un brazo. Cada día sin una nueva característica te parece perdido. Pero es exactamente lo contrario: cada micro-fricción eliminada, cada error silencioso corregido, es un usuario más que no desinstala después de 3 días.

Este sprint sigue al sprint de calidad anterior que ya había corregido los recordatorios y los correos electrónicos. Esta vez, las correcciones afectan el corazón de la aplicación.

¿Cómo hacer que un botón de parada sea 100% fiable en una grabadora de voz?

El error más frustrante de la aplicación: a veces, el botón "detener" no respondía. El micrófono seguía grabando, el usuario tenía que forzar la detención. Una pesadilla de UX absoluta.

¿La causa? Un problema de sincronización entre la inicialización del STT nativo (reconocimiento de voz del teléfono) y el estado de React. Cuando el usuario presionaba detener durante una ventana de unos pocos milisegundos en la que el STT estaba en transición entre dos estados, la devolución de llamada de detención simplemente se ignoraba.

La solución técnica en 3 puntos

• Modo "standby" para el STT nativo: en lugar de inicializar completamente el STT cada vez que se presiona el botón del micrófono, permanece en estado de espera activa. Resultado: inicio 2 veces más rápido, sin espera de devolución de llamada.
• Botón de parada absoluto: independientemente del estado interno del STT (inicialización, escucha, procesamiento), el botón de parada activa una detención forzada. Sin condiciones, sin "esperar a que la devolución de llamada regrese".
• Limpieza de seguridad: un tiempo de espera de 30 segundos limpia automáticamente cualquier estado residual, inspirado en el patrón utilizado en el AudioPlayerService.

Esta corrección es quizás la más importante de todo el sprint. El pipeline de voz es el corazón de TAMSIV. Si el botón de grabación no es 100% fiable, nada más importa.

¿Cómo hacer que una IA de voz entienda los rangos de fechas?

Antes, preguntar "¿qué tengo esta semana?" a la IA solo funcionaba para un día. El system prompt limitaba las solicitudes a una fecha única. Un problema típico del diseño de prompts para la IA conversacional.

La solución requirió dos modificaciones:

1. Extensión del system prompt: se agregaron ejemplos de rangos de fechas ("de lunes a viernes", "los próximos 3 días", "esta semana") en las instrucciones de la IA.
2. Modificación de la llamada a función: la herramienta create_calendar_event ahora acepta un parámetro opcional end_date para las solicitudes que cubren un rango.

Ahora, el asistente entiende los rangos: "de lunes a viernes", "los próximos 3 días", "esta semana". Es un cambio sutil pero que transforma el uso de la agenda en el día a día.

¿Por qué pasar de SDXL a HiDream para la generación de imágenes de IA?

Las imágenes de portada de las carpetas en TAMSIV son generadas por IA. Usábamos SDXL 0.9, que tenía dos problemas principales: entendía mal los prompts complejos (texto mezclado, instrucciones ignoradas) y la calidad era inconsistente.

El cambio a HiDream-I1-Fast a través de Runware lo cambió todo. Mejor comprensión del prompt, resultados más coherentes y un costo de ~0.003 EUR por imagen. Es el mismo modelo que uso para las imágenes de IA en línea en la grabadora de voz; la coherencia visual se mantiene en toda la aplicación.

¿Cómo detectar una fuga de datos entre sesiones de usuario?

Un error crítico descubierto y corregido durante este sprint: en un dispositivo compartido, los datos del usuario anterior podían aparecer brevemente al cambiar de cuenta. La caché singleton no se vaciaba al cerrar sesión.

Este es un error de seguridad de clase crítica. Aunque la exposición es breve (unos pocos cientos de milisegundos), un usuario puede ver las tareas, notas o eventos de otro usuario. En una aplicación de productividad que gestiona datos personales, esto es inaceptable.

La corrección: limpieza completa al cerrar sesión

La solución es simple en teoría pero requiere rigor: cada servicio singleton (ContentCacheService, CalendarService, GamificationService) recibió un método clearAll() que se llama sistemáticamente en cada cierre de sesión. El sistema de seguridad de TAMSIV ahora incluye una verificación de que todas las cachés están vacías antes de inicializar una nueva sesión.

¿Cuál es el impacto combinado del video y el sprint de calidad?

El video y el sprint de calidad son dos caras de la misma moneda:

• El video es el escaparate: hace que el proyecto sea tangible para alguien que nunca ha tocado la aplicación. Es la herramienta de adquisición.
• El sprint de calidad son los cimientos: marca la diferencia entre una aplicación que se prueba y una aplicación que se conserva. Es la herramienta de retención.

Ambos se complementan perfectamente. Atraer usuarios con un buen video para perderlos debido a un botón de parada defectuoso sería un desastre. Por el contrario, una aplicación perfectamente pulida que nadie conoce no sirve de nada.

Esta es exactamente la lógica que detallo en el artículo sobre el recorrido de los más de 650 commits: cada fase del proyecto alterna entre características visibles y pulido invisible.

¿Qué lecciones aprender para un desarrollador individual que lanza su aplicación?

Después de esta semana, esto es lo que me llevo:

1. Graba tu video pronto. No esperes a que la aplicación sea "perfecta". Un video de 2 minutos con un producto funcional vale más que meses de descripciones textuales.
2. Planifica tus sprints de calidad. Bloquea una semana de cada dos sin ninguna característica. El sprint de cero características se ha convertido en un ritual para mí.
3. El botón principal debe ser infalible. Para TAMSIV, es el botón del micrófono. Para ti, es el botón que representa tu propuesta de valor principal. Si falla una vez, pierdes la confianza.
4. Verifica la seguridad de los singletons al cerrar sesión. Si utilizas cachés en memoria en una aplicación móvil, asegúrate de que se limpien en cada cambio de sesión.

Preguntas frecuentes

¿Cuánto tiempo se tarda en grabar un video de demostración de una aplicación móvil?

Para TAMSIV, el video de 2 minutos requirió aproximadamente medio día: preparación del guion, 3 tomas, edición básica. No se necesita un estudio profesional; una buena iluminación y una pantalla bien encuadrada son suficientes. Lo importante es mostrar la interacción real, no un mockup.

¿Se debe hacer un sprint de calidad antes o después del lanzamiento?

Ambos. Antes del lanzamiento, un sprint de calidad se enfoca en las fricciones más visibles (como el botón de parada). Después del lanzamiento, los comentarios de los usuarios guían las prioridades. Recomiendo un sprint de calidad cada 2 semanas durante la fase beta.

¿El modo de espera del STT consume más batería?

No, el modo de espera mantiene el módulo STT en memoria pero no inicia la escucha activa. El consumo de batería es insignificante en comparación con la grabación activa. Es comparable a mantener una conexión SpeechRecognizer inicializada sin iniciarla.

¿Cómo evitar fugas de datos entre sesiones en un dispositivo compartido?

Tres reglas: (1) cada servicio singleton debe tener un método clearAll(), (2) este método se llama en el controlador de cierre de sesión, (3) una prueba automatizada verifica que todas las cachés estén vacías después del cierre de sesión. Es básico pero a menudo se olvida en arquitecturas basadas en singletons.

¿HiDream-I1-Fast es mejor que SDXL para la generación de imágenes de aplicaciones?

Para imágenes de portada e ilustraciones contextuales, sí. HiDream comprende mejor los prompts complejos y produce resultados más coherentes. SDXL sigue siendo relevante para el fotorrealismo puro, pero para imágenes funcionales en una aplicación móvil, HiDream es una mejor opción con un costo similar (~0.003 EUR/imagen).