Capstone: del prototipo al producto

Seis semanas después

Hagamos cuentas. Seis semanas después de la primera línea de prompt, la app de Tom la usan tres clases en dos institutos. El profe de mates ha pagado su versión «clase» vía el Payment Link. Lina exhibe una racha de 34 días. Y Tom ha recibido esta semana cuatro mensajes: dos ideas de funcionalidades, una pregunta, un bug menor. Es el momento bisagra que conocen todos los creadores: la app funciona — pero una app que funciona todavía no es un producto. Un producto es una app más un bucle: se mide, se escucha, se decide, se itera. Este capítulo instala ese bucle, y luego te envía hacia tu próximo proyecto.

Medir: cifras sin espiar

Primera pregunta de un responsable de producto: «¿quién usa qué, de verdad?». Las impresiones mienten — las cifras, menos. Pero cuidado con el reflejo «Google Analytics»: para una app pequeña, sobre todo usada por menores, quieres una herramienta de analítica respetuosa con la privacidad como Plausible o Umami: sin cookies, sin perfilado, sin banner de consentimiento interminable, solo contadores anónimos. La integración cabe en una línea que la IA añadirá en treinta segundos, y el panel te dice lo esencial: cuántas visitas, qué páginas, qué días.

La siguiente trampa es mirar las cifras equivocadas. El número de visitas halaga el ego pero no dice nada útil: a eso se le llama una métrica de vanidad. Tom se elige una métrica norte — LA cifra que dice si la app cumple su misión: «¿cuántos alumnos marcan al menos un hábito tres días por semana?». Todo lo demás (visitas, cuentas creadas, páginas vistas) es solo decorado alrededor de esa pregunta. Elige la tuya con el mismo criterio: si esa cifra sube, tu app presta objetivamente más servicio.

Escuchar: organizar el feedback

Los mensajes dispersos de Tom — un SMS, dos correos, una palabra en el recreo — son el síntoma de un producto sin canal de feedback. La solución está en la propia app: un pequeño botón «¿una idea? ¿un problema?», un miniformulario, y cada envío guardado en una tabla de la base. Tienes todas las competencias para construirlo — es incluso un excelente ejercicio de síntesis de los capítulos 6 a 9: un formulario (¡entradas validadas!), una tabla de Supabase (¡con RLS!), un límite de envíos (¡capítulo 9!):

Añade un módulo de feedback a mi app de seguimiento de hábitos.
Lo que quiero:
1. un pequeño botón discreto «¿una idea? ¿un problema?» abajo de la página principal
2. al hacer clic: un miniformulario con un campo de texto de 500 caracteres máx y una elección «bug / idea / otro»
3. cada envío se registra en una tabla feedback de Supabase con el user_id, la categoría y la fecha — con la Row Level Security activada
4. límites: 5 envíos por usuario y por día, validación del contenido en el lado servidor, mensaje de agradecimiento tras el envío
5. crea también una página /admin accesible únicamente con mi cuenta, que liste los feedbacks del más reciente al más antiguo con un contador por categoría
Una etapa a la vez, pruebo antes de continuar.

Una vez el módulo en marcha, la regla de interpretación: las peticiones no son necesidades. Cuando tres alumnos piden «un modo oscuro», la necesidad real quizá sea «la app me deslumbra por la noche en el dormitorio». Antes de añadir lo que te piden, remonta al problema: «¿qué te molesta, en concreto, en qué momento?». A veces la buena respuesta es la funcionalidad pedida; a menudo, es una solución más simple que nadie había formulado.

Priorizar: la matriz del constructor en solitario

Con la analítica por un lado y el feedback por el otro, tu lista «más adelante» va a engordar rápido. La criba se hace con cuatro preguntas, en este orden: ¿a cuántos usuarios afecta? (una molestia citada cinco veces gana a una idea brillante citada una vez), ¿está alineado con tu métrica norte? (una funcionalidad que no ayuda a la misión esperará), ¿qué esfuerzo? (pide a la IA que lo estime: obra pequeña, mediana, grande), y ¿es reversible? (una experimentación que se puede retirar se intenta con más libertad que un compromiso definitivo).

• Muchos usuarios + alineado + esfuerzo pequeño: hazlo esta semana.
• Alineado pero gran esfuerzo: trocéalo en mini-PRD (capítulo 3) y repártelo en el tiempo.
• Pocos usuarios afectados: déjalo madurar — si vuelve tres veces, subirá solo.
• No alineado con la misión: rechaza educadamente, aunque sea una buena idea. Sobre todo si es una buena idea.

El último punto es el más duro y el más importante: decir no. Cada funcionalidad añadida es una superficie que mantener, depurar y asegurar para siempre. Los mejores productos no son los que hacen más cosas, son aquellos en los que cada cosa sirve a la misión. Tom rechaza así un «chat entre alumnos» — excelente idea, mal producto: su misión son los hábitos, no la mensajería.

Monetizar sin traicionarse

El Payment Link del capítulo 8 transformó la app de Tom en una actividad que genera ingresos — modestamente, pero de verdad. Ha llegado el momento de reflexionar con calma. Los modelos adaptados a una app pequeña: el freemium (el núcleo gratuito, comodidades de pago — la elección de Tom: gratis para los alumnos, versión «clase» con panel para los profes), el pago único (simple y honesto, adaptado a las herramientas), la donación (viable para una herramienta querida por una comunidad), y la suscripción (reservada a un valor recurrente evidente — no se la impongas a una herramienta que se usa dos veces al mes).

Dos principios a la hora de fijar el precio. Primero, la coherencia con la misión: Tom nunca hará pagar a un alumno — la misión es pedagógica, son los centros y los profes quienes financian. Después, la simplicidad: un solo plan de pago, un precio redondo, una página que lo explica en tres beneficios. Podrás complejizar cuando tengas cien clientes; con cinco clientes, cada hora dedicada a la parrilla tarifaria es una hora robada al producto.

Darse a conocer: mostrar el problema, no la técnica

El boca a boca trajo tres clases a Tom; para ir más lejos, necesita una verdadera página de inicio — la que un profe descubre al hacer clic en el enlace compartido en la sala de profesores. Regla de oro del principiante: no se vende la técnica, se muestra el problema resuelto. Nadie se registra por «una app Supabase con RLS»; uno se registra por «ayudar a sus alumnos a mantener sus rutinas de trabajo». Tom la hace generar con todo su saber hacer de prompts:

Crea una página de inicio de marketing para mi app de seguimiento de hábitos, en la ruta /inicio.
Audiencia: profesores de instituto que descubren la app a través de un colega — no desarrolladores.
Estructura:
1. un título que hable del problema resuelto: ayudar a los alumnos a mantener sus rutinas de trabajo
2. tres beneficios concretos en tres tarjetas, sin ninguna jerga técnica
3. una captura de pantalla de la app en el centro, limpia, sobre fondo claro
4. un breve testimonio de profe — te proporcionaré el texto exacto
5. dos botones: «probar gratis» hacia el registro, y «versión clase» hacia la página de pago
Estilo: coherente con la app, depurado, acento verde, tranquilizador, legible en el teléfono.
La página debe cargar rápido: sin animaciones pesadas, sin bibliotecas inútiles.

El ritmo sostenible: iterar sin agotarse

Último ingrediente del producto: el ritmo. El error clásico tras el lanzamiento es el sprint permanente — tres funcionalidades por semana durante un mes, y luego el abandono completo. El ritmo sostenible del constructor en solitario se parece más bien a esto: una mejora por semana, elegida por la matriz de priorización, entregada según el método de los capítulos 3-4 (mini-PRD si es grande, construir-probar-commitear siempre), más un cuarto de hora de higiene semanal: un ojo a la analítica, la criba de los feedbacks, un vistazo a las páginas de estado y al techo de gasto de IA.

Y acepta una idea contraintuitiva: un producto puede estar terminado. Si la métrica norte es buena, los feedbacks se agotan y la app presta exactamente el servicio previsto, tienes derecho a dejarla funcionar en modo mantenimiento y pasar a otra cosa. «Terminado y útil» es un estado glorioso, no un fracaso de ambición. No todas las apps tienen vocación de convertirse en imperios — la de Tom hace precisamente lo que debe hacer, y esa es su mayor cualidad.

Tu recorrido — y el siguiente proyecto

Tómate un segundo para medir el camino, porque es considerable. En diez capítulos, has aprendido a encuadrar una idea (mini-PRD), elegir herramientas, construir iterando, depurar metódicamente, desplegar, autenticar usuarios, centralizar datos con seguridad, conectar servicios externos, asegurar el conjunto, y pilotar un producto con cifras y feedback. No son conocimientos de «vibe coder principiante»: es, muy exactamente, el ciclo de vida completo de un producto de software — el que siguen los equipos profesionales, y que ahora sabes desplegar dialogando con una IA.

La continuación se escribe sola: elige un segundo proyecto, un punto más ambicioso, y vuelve a desplegar el ciclo entero. Irás tres veces más rápido — no porque la IA haya progresado, sino porque tú sabrás qué pedir, qué exigir, qué probar y cuándo decir no. Ese era el objetivo secreto de este curso desde la primera página: no enseñarte a hacer una app, enseñarte a hacer tantas como quieras. Tom ya tiene su siguiente idea — un cuaderno de lectura para el club de la biblioteca. ¿Y tú?