Durante mucho tiempo, probé LowFlow como alguien que conocía el sistema.
Sabía dónde hacer clic. Sabía qué datos debían aparecer. Sabía dónde mirar cuando faltaba una información.
Podía abrir el servidor, consultar los logs, revisar un archivo, modificar una configuración, reiniciar un servicio.
En resumen, probaba como quien había construido LowFlow.
Pero un cliente nunca hará eso.
Y ahí es donde otro tipo de prueba se vuelve necesario.
La prueba técnica ya no basta
Un botón puede funcionar. Una ruta del servidor puede responder correctamente. Stripe puede confirmar un pago. Una licencia puede generarse. La descarga puede existir.
Todo eso puede ser cierto por separado.
Pero el cliente no prueba las piezas. Prueba el recorrido completo.
Llega al sitio. Elige. Crea su cuenta. Confirma su correo. Paga. Vuelve a LowFlow. Descarga. Instala. Abre la aplicación. Activa su máquina.
Y si uno solo de esos pasos está mal conectado con el siguiente, su experiencia se detiene ahí.
Hacía falta una persona real
Para esta prueba, ya no quería simular al cliente yo mismo.
Siempre podía, inconscientemente, esquivar un problema porque conocía el sistema.
Hacía falta alguien que usara el recorrido tal como se presenta.
Un amigo me ayudó con eso.
Una segunda máquina. Otra computadora. Un navegador real. Un correo real. Una tarjeta real.
Y sobre todo, alguien que nunca debería necesitar entender la arquitectura detrás de LowFlow.
Si había que explicarle una manipulación técnica para continuar, la prueba ya había revelado un problema.
Probar con pagos reales, sin pagar 200 dólares cada vez
También quería probar Stripe en condiciones reales. No solo en simulación.
Pero hacer pagar 199,99 $ solo para verificar un recorrido habría sido absurdo.
Así que creé tres ofertas temporales de validación que reproducen los tres caminos comerciales de LowFlow:
1A — pago completo: 1,00 $
1B — plan de 12 meses: 0,75 $
1C — plan de 24 meses: 0,50 $
Las ofertas reales permanecen sin cambios. El único objetivo es hacer circular un pequeño pago real por el sistema real.
Mismo sitio. Mismo Stripe. Misma cuenta. Mismo servidor. Misma lógica de activación.
Lo único diferente es el monto.
Y ahí es donde aparecen los verdaderos problemas
La primera lección fue brutalmente simple.
Un pago exitoso no significa un recorrido exitoso.
Stripe podía aceptar la tarjeta. La transacción podía aparecer en el panel.
Pero si el servidor no escuchaba el evento correcto, LowFlow no sabía a qué cliente atribuir el pago.
Stripe tenía el dinero. El servidor había recibido algo. Pero el cliente no tenía ningún derecho adicional.
Técnicamente, varios sistemas habían funcionado. Comercialmente, nada había funcionado.
Luego el cliente pagaba… y caía en el vacío
Otro problema.
El pago pasaba. Pero después del pago, Stripe simplemente mostraba su propia confirmación.
Ningún regreso claro hacia LowFlow. Ninguna descarga. Ningún paso siguiente.
El cliente acababa de pagar y tenía que adivinar qué hacer después.
Era exactamente lo contrario de lo que había querido construir.
La maqueta original ya había definido el recorrido: pago confirmado, luego descargar LowFlow, luego instalar y abrir la aplicación, luego terminar la activación.
El sitio real debía respetar esa secuencia.
El regreso de Stripe fue conectado a una página LowFlow dedicada. El pago ya no es un final. Se convierte en una transición hacia lo que sigue.
El cliente que vuelve también reveló un hueco
Otra prueba mostró algo aún más evidente.
¿Qué pasa si alguien ya tiene una cuenta?
No debería tener que recrear su cuenta. No debería tener que recordar su LF-ID de memoria. Debería ingresar su correo y su contraseña, recuperar su cuenta, elegir su producto y continuar.
La página de inicio de sesión ya existía. La página de precios ya existía. Pero las dos no estaban suficientemente conectadas.
Una vez más, todas las piezas existían. El recorrido, en cambio, estaba incompleto.
La prueba gratuita recibió el mismo tratamiento
En un momento, tuve una duda sobre la prueba gratuita.
Algo no me parecía lógico.
Verifiqué. Y la duda estaba justificada.
La validación de la cuenta no desbloqueaba la descarga.
El botón existía. La página existía. El sistema de prueba existía. Pero el cliente no habría podido descargar realmente la aplicación.
Exactamente por eso la prueba del recorrido completo es diferente. Hace aparecer los huecos situados entre dos funciones.
La verdadera prueba empieza después de la instalación
Después del sitio y de Stripe viene la parte que había pasado mucho tiempo construyendo: la activación.
Una máquina nueva abre LowFlow. Todavía no posee ninguna licencia.
El cliente ingresa su correo y su identificador LowFlow. La máquina queda vinculada a la cuenta. Y la licencia llega sola.
El cliente nunca tuvo que copiar una clave de licencia.
Ese era exactamente el objetivo.
Pero la activación no es la última verificación
Quedaba una prueba importante.
Una licencia permanente no debe convertirse en un permiso para eludir las protecciones.
La prueba final es deliberadamente simple:
La máquina posee una licencia real. Está activada. Luego, desde el servidor, le retiro el acceso.
Si LowFlow sigue funcionando normalmente, la arquitectura está mal. Si la aplicación respeta el veredicto del servidor, entonces la separación entre Activación y Acceso funciona de verdad.
Esa diferencia era lo importante desde el principio.
Pagado no significa inmune. Activado no significa incontrolable.
El probador nunca debe convertirse en el desarrollador
Una regla salió muy claramente de esa jornada.
Nunca quiero pedirle a un cliente que abra herramientas técnicas, que copie mensajes de error, o que me explique lo que responde el servidor.
Si algo no funciona, me toca a mí mirar los logs, el código y el servidor.
El cliente debe seguir siendo el cliente. Su único trabajo es usar LowFlow normalmente.
Y eso es precisamente lo que hace que su prueba sea valiosa.
Stripe también debía probarse como un sistema completo
Recorriendo el panel de Stripe, descubrí algo similar.
Recibir un pago es solo una pequeña parte de la configuración.
Están los recibos. Las notificaciones. Las tarjetas expiradas. Los pagos fallidos. Las confirmaciones adicionales. El portal del cliente. Las suscripciones. Los reembolsos. Las redirecciones. Las alertas de error. Las reglas antifraude.
Un solo ajuste olvidado puede romper una parte de la experiencia.
Una vez más: los detalles se quedan detrás de la pantalla, pero alguien tiene que verificarlos.
Al final, probar un producto no es verificar que abre
Antes, podía decir: LowFlow arranca. Los trades entran. Los cálculos funcionan. Los datos permanecen locales. Las actualizaciones funcionan.
Todo eso sigue siendo importante. Pero ya no es suficiente.
Ahora, probar LowFlow también significa:
¿Alguien puede descubrirlo? ¿Crear su cuenta? ¿Volver más tarde? ¿Pagar? ¿Recibir lo que acaba de comprar? ¿Instalar la aplicación? ¿Activar su máquina? ¿Gestionar su suscripción? ¿Recibir ayuda correctamente si algo falla?
¿Y mis protecciones siguen funcionando una vez que todo lo demás funciona?
Es otro nivel de prueba.
Porque LowFlow ya no es solo un programa. Ahora es un recorrido completo.
¿Y después?
A partir de ahí, las próximas mejoras se vuelven mucho más fáciles de identificar.
Agregar varias máquinas a una cuenta. Permitir la compra de un segundo lugar. Encuadrar las migraciones de computadora. Seguir mejorando las páginas de cuenta. Continuar las traducciones. Agregar los próximos mercados y plataformas.
Pero esta vez, la base comercial existe.
Alguien puede llegar. Comprar. Instalar. Activar. Y empezar a usar LowFlow.
Sin necesidad de conocer todo lo que fue necesario para hacerlo posible.
Y esa es probablemente la mejor señal de que LowFlow realmente empieza a convertirse en un producto.