Construir la aplicación era una cosa.
Hacerla funcionar en mi propia máquina era otra.
Pero ahora quería que alguien que ni siquiera conozco pudiera comprar LowFlow, recibir su acceso, instalar la aplicación y empezar a usarla.
Y ahí me di cuenta de algo: ya no estaba construyendo solo un software. Estaba construyendo un sistema capaz de entregar un software.
El cliente no debía tener que escribirme
Quería evitar el escenario clásico. Un cliente compra. Me envía un correo. Le respondo. Le envío un archivo. Le explico cómo instalarlo. Luego vuelve porque cambió de computadora. Luego otra vez porque quiere una actualización. Y así sucesivamente.
Si quería tener decenas, y luego cientos de clientes, ese modelo no podía funcionar. Había que automatizar al máximo. El cliente debía poder hacer su compra y recibir lo que necesitaba sin que yo tuviera que intervenir manualmente en cada paso.
La cuenta del cliente
Había que empezar por el principio. Una cuenta. El cliente debía poder ser identificado en mi sistema. Su compra debía estar asociada a su cuenta. Su acceso debía estar asociado a su producto. Y su aplicación debía poder comunicarse con esa información.
Parece simple visto desde fuera. Pero detrás de una pequeña ventana de inicio de sesión, hay muchas cosas que deben ser coherentes — el cliente correcto, el producto correcto, la licencia correcta, la versión correcta, y el dispositivo correcto.
La licencia
Luego llegó la cuestión de la licencia. No quería simplemente enviar un archivo ejecutable diciendo: «Toma, diviértete».
LowFlow tenía que saber si la persona que lo usaba realmente tenía un acceso válido. La licencia se convirtió entonces en una pieza central del sistema. Permite vincular al cliente con el producto que compró y gestionar su acceso a lo largo del tiempo.
Pero, de nuevo, quería conservar la misma filosofía. El diario se queda local. La licencia, en cambio, se verifica a distancia.
¿Y la instalación?
Luego había que distribuir la aplicación. Quería evitar poner mis archivos de producción públicamente a disposición de cualquiera. Había que crear entonces un sistema donde el cliente pudiera obtener la versión correcta de LowFlow sin exponer toda mi infraestructura de desarrollo.
Ahí es donde mi Control Panel empezó a tomar aún más importancia. Se convirtió en el centro de gestión de todo lo que debía distribuirse.
Una versión no es simplemente un archivo
Al principio, uno podría pensar que una actualización simplemente consiste en reemplazar un archivo viejo por uno nuevo. En realidad, no es tan simple.
Hay que saber qué versión está usando el cliente. Hay que saber qué versión está disponible. Hay que poder verificar que el archivo recibido corresponde realmente a lo que debe instalarse. Y hay que evitar que un cliente descargue cualquier cosa.
Empecé entonces a construir una cadena mucho más estructurada: una versión, un control, una distribución, una instalación, y luego una nueva versión cuando fuera necesario.
Quería que funcionara sin mí
Ese era probablemente el punto más importante. No quería crear una empresa donde cada nuevo cliente me diera una nueva tarea manual. Quería construir el sistema una vez. Y luego dejar que el sistema hiciera el trabajo.
El cliente compra. Se crea su acceso. Obtiene su aplicación. La aplicación se comunica con la infraestructura. La licencia se verifica. Y LowFlow arranca.
Todo lo que se puede automatizar debe automatizarse. Porque mi objetivo no es pasar mis días enviando archivos y activando licencias. Quiero desarrollar LowFlow.
¿Y las actualizaciones?
Una vez resuelta la distribución, otra pregunta se volvió evidente. ¿Qué pasa cuando LowFlow evoluciona? Porque LowFlow evoluciona constantemente. Una corrección hoy. Una nueva función mañana. Una optimización la semana que viene.
No podía pedirle a cada cliente que descargara manualmente una nueva versión cada vez que hubiera un cambio. Había que pensar entonces desde ya en la actualización. La aplicación debía poder saber si había una nueva versión disponible y obtener la versión correcta cuando fuera necesario.
Una vez más, el objetivo era el mismo: la menor intervención posible.
El sistema empezaba a tomar forma
En este punto, LowFlow tenía ya varias piezas que debían funcionar juntas: la aplicación local, los datos del trader, la cuenta del cliente, las licencias, el Control Panel, la distribución, las actualizaciones, y la infraestructura que permitía que todo esto se comunicara.
Y sin embargo, el corazón de LowFlow no había cambiado. El trader seguía trabajando con sus propios datos, en su propia máquina. No había convertido el diario en un SaaS. Simplemente había construido alrededor de la aplicación local lo que necesitaba para poder comercializarla correctamente.
Pero apareció una nueva pregunta
Mientras más construía el sistema, más evidente se volvía otra realidad. Si realmente quería distribuir LowFlow a clientes, tenía que proteger todo lo que acababa de construir.
No solo la aplicación. La licencia. Las actualizaciones. La distribución. La infraestructura.
Y sobre todo, tenía que asegurarme de que el sistema pudiera distinguir entre una instalación legítima y algo que no debería tener acceso al producto.
Acababa de terminar una etapa. Y descubría que la siguiente iba a ser mucho más seria. La protección de LowFlow.