Hasta este punto, LowFlow podía funcionar.
El sitio existía. El sistema de cuentas existía. Stripe podía recibir un pago. El servidor podía gestionar las licencias. La aplicación podía instalarse. El Control Panel podía gestionar a los clientes.
Todas las piezas estaban ahí.
Pero tener todas las piezas no significa que el cliente pueda realmente pasar de una a otra.
Y esa es probablemente una de las lecciones más importantes de toda esta construcción.
Un cliente no ve la arquitectura
Para mí, LowFlow se había convertido en un conjunto bastante complejo.
Estaba el sitio. El servidor. Stripe. Las cuentas. Los correos de verificación. Los identificadores LowFlow. Las descargas. Las licencias. Las activaciones. Los controles de seguridad.
Pero el cliente nunca debería tener que entender todo eso.
Para él, el recorrido debería ser mucho más simple.
Descubre LowFlow. Elige una fórmula. Crea su cuenta o inicia sesión. Paga. Descarga. Instala. Abre LowFlow. Y empieza a trabajar.
Todo lo que hay entre esos pasos debe quedarse detrás de la pantalla.
El verdadero desafío era conectar las piezas
Ahí fue cuando entendí una diferencia importante.
Construir una función es una cosa. Construir un recorrido completo es otra.
Un pago de Stripe puede funcionar perfectamente, pero si el cliente se queda en una página de confirmación sin saber qué hacer después, el recorrido está roto.
Una descarga puede estar protegida, pero si el enlace nunca llega al cliente, el recorrido está roto.
Cada pieza puede funcionar por separado. Y aun así, el conjunto puede no funcionar.
El pago no debía ser el final
Al principio, veía a Stripe sobre todo como el sistema que recibiría el pago.
Pero en un producto real, el pago no es el final. Es una transición.
Una vez confirmado el pago, LowFlow debe saber qué acaba de pasar.
La cuenta debe ser reconocida. El derecho debe ser otorgado. El cliente debe volver al sitio. Debe ver claramente que su pago está confirmado. Debe poder descargar la aplicación. Luego la aplicación toma el relevo.
El pago se convierte así en el punto donde el sitio, Stripe, el servidor y la aplicación empiezan realmente a trabajar juntos.
El cliente que vuelve cuenta tanto como el nuevo
Otro detalle parece evidente después.
Un cliente no visita el sitio una sola vez en su vida.
Puede volver. Puede olvidar su identificador LowFlow. Puede cambiar de computadora. Puede querer descargar la aplicación de nuevo. Puede querer gestionar su suscripción. Puede simplemente querer consultar su cuenta.
Había que dejar de pensar únicamente en el recorrido «crear una cuenta → comprar» y construir también «iniciar sesión → recuperar su cuenta → continuar».
El correo y la contraseña deben bastar para recuperar la cuenta. El identificador LowFlow sigue siendo importante, pero no debe convertirse en algo que el cliente tenga que memorizar para acceder a lo que compró.
Un solo paso olvidado basta
Esto es probablemente lo que más me sorprendió.
Basta un solo paso faltante para dar la impresión de que todo el sistema no funciona.
El pago puede tener éxito. El servidor puede recibir el evento. La transacción puede aparecer en Stripe.
Pero si el cliente no vuelve automáticamente hacia LowFlow, no ve nada de eso.
Para él, simplemente acaba de pagar. Y después… nada.
Es exactamente el tipo de problema que no se ve necesariamente cuando se prueba cada función por separado.
La maqueta ya tenía la respuesta
Lo casi divertido es que yo ya había dibujado este recorrido.
En mi maqueta local, los pasos eran simples: cuenta creada, correo verificado, identificador LowFlow, pago confirmado, descarga, computadora activada.
Todo ya estaba ahí.
El trabajo no era entonces inventar un nuevo proceso. Había que tomar ese recorrido y asegurarse de que el sitio real, el servidor real, Stripe y la aplicación real lo respetaran de verdad.
El recorrido se convierte en una función del producto
A partir de ese momento, dejé de ver el sitio como una simple vitrina.
El recorrido del cliente ahora forma parte de LowFlow.
Iniciar sesión forma parte del producto. El regreso después del pago forma parte del producto. La descarga forma parte del producto. La activación forma parte del producto.
Incluso los correos enviados cuando un pago falla o cuando una tarjeta expira forman parte de la experiencia.
LowFlow ya no empieza únicamente cuando la aplicación se abre. Empieza en el momento en que alguien decide usarlo.
La complejidad debe desaparecer
Detrás de este recorrido, hay muchísimas cosas.
Verificaciones. Automatismos. Intercambios constantes entre el sitio, el servidor y la aplicación.
Pero si el sistema está bien construido, el cliente casi nunca debería ver esa complejidad.
Debería simplemente avanzar. Un paso tras otro.
Y si algo requiere su atención, el sistema debe decirle claramente qué hacer.
Ahí entendí que una buena automatización no es simplemente algo que trabaja sin intervención. Es algo que hace desaparecer la mecánica.
El siguiente paso: dejar de probar como el desarrollador
Una vez construido el recorrido, quedaba una pregunta.
¿Funcionaba realmente?
No cuando yo ya conocía todos los botones. No cuando podía mirar los logs. No cuando podía abrir el servidor y corregir un dato a mano.
Sino cuando otra persona llegaba al sitio sin conocer nada de lo que pasa detrás.
Ahí el siguiente test se volvía evidente.
Había que dejar de probar LowFlow como quien lo construyó. Y empezar a probarlo como alguien que simplemente acaba de comprarlo.