Entonces, ahí estaba yo, planeando (cómo empezar) a configurar mi arquitectura. Digo, al fin y al cabo, tenemos que diseñar nuestros sistemas para que sean escalables, sólidos y seguros. Quizás tengo que mirar más literatura y casos de éxito. Bueno, existen muchos casos bien documentados de las lecciones y aplicaciones en diferentes compañías, pero aquí surge una pregunta clave, o bueno, por lo menos en ese momento para mí fue clave: ¿y tus usuarios?

Vamos, me considero una persona que se energiza cuando hay que aprender cosas técnicas; no importa la magnitud o la dificultad, siempre me enamoro de los conceptos que aprendo. Pero en el trayecto en el que estoy caminando actualmente, la intersección del conocimiento técnico y la startup no siempre es un 50/50. Y creo que no hay una proporción correcta del todo; a todo momento (y me refiero a constantemente), la proporción cambia de un lado a otro, y creo que es momento de enfocarnos en el primer cincuenta por ciento de esta proporción.

En este espacio te compartiré lo que (yo) he experimentado y me ha funcionado para llevar mi proyecto a otra etapa, claro, no en el sentido de negocio, sino técnico y, más que nada, en esta etapa en la que estamos muchos.

¿Que hacemos en RecoImage y por que es importante tomar decisiones tecnicas en esta etapa?

Probablemente, en algún momento de este año te haya surgido la curiosidad de remodelar tu hogar. Si eres una corporación o empresa, quizás haya una serie of de oficinas que tienen que seguir la misma suerte. Es normal, el cambio está en nuestro ADN. Pero, ¿cómo desarrollarías este proyecto? Muchos de nosotros conocemos ese proceso: contactar, comunicar y (rogar) por un presupuesto. Casi la gran mayoría de veces, el resultado no es satisfactorio por las diferentes variables que entran en este proceso, como la comunicación (o la falta de esta), la complejidad en los precios, el conocimiento técnico, etc. Imagínate multiplicar este proceso unas diez veces más. Al final, no es sorprendente el porqué muchos también deciden no embarcarse en este proceso en primer lugar y, vamos, no es culpa del proceso, sino de las herramientas que utilizamos.

En RecoImage vamos por ese reto: queremos crear las herramientas para que la estimación en construcción no solo tenga esa imagen manual que siempre viene a la mente, sino que sea una herramienta de estimación tecnológica, potenciada con IA y algoritmos de Computer Vision. Eso es RecoImage.

Esto, claro, tiene muchas partes, componentes y tecnologías que se unen al unísono para proveer al usuario una herramienta de estimación. Evidentemente, no existe un manual, así que sí, por el momento estás solo (no tanto). La pregunta que siempre surge es: ¿cómo iniciamos? Aquí es donde empieza un reto muy excitante y, claro, gratificante, but también técnicamente complejo, ya que aquí es donde se decide si puedes validar tu idea o si simplemente dimos vueltas en círculo sin ningún tipo de feedback de dónde estamos.

No desarrolles tu arquitectura, implementala

Tener una arquitectura importa mucho. Tu proyecto, en algún momento, va a servir en tiempo real, con operaciones diferentes, en distintas zonas horarias, con diversas cargas de trabajo y con múltiples resultados, todo al mismo tiempo. Imagina esto multiplicado por diez (tu base de usuarios escaló a más de un millón de usuarios activos al día). Pero la palabra clave aquí es «en algún momento», no ahora, no en la etapa en la que nos encontramos.

Es importante pensar en una arquitectura que sea escalable, confiable y segura, pero no para este momento.

Muchos de nosotros sabemos cómo podemos desarrollar una arquitectura escalable (o una aproximación) a través de algún proveedor de la nube, ya sea AWS, Google Cloud o Azure, e incluso podemos dar otros nombres como DigitalOcean o Supabase; pero en esta etapa, no podemos darnos ese lujo.

Mira, tenemos que validar nuestra idea, más temprano que tarde, y poner todas nuestras horas de desarrollo en documentar e investigar una arquitectura como si tuviéramos más de un millón de usuarios es, simplemente, una pérdida de tiempo. Inicia desde abajo e implementa, pero, lo más importante, crea tu arquitectura con base en esta pequeña base de usuarios que tienes o vas a tener. Nada de clústeres de Kubernetes, nada de auto-scaling entre diferentes regiones, nada de load balancer; solamente un bote que todavía pueda mantenerse a flote. Suena sucio, pero esto va a potenciar tu proyecto a futuro.

Desarrolla tu arquitectura, pero un poquito

Es importante tener una arquitectura que sirva lo suficiente, pero, aun así, es importante saber hacia dónde estás yendo. Este es como el mítico caso del bosque donde no tienes brújula, pero sí un mapa. Quizás el mapa no tenga nada, pero aquí es donde tú decides hasta dónde es el destino. Tu mapa, en este caso, va a ser tu guía. Así, tu arquitectura también va a ser tu guía.

Si tenemos horas de desarrollo libres en la semana, empléalas en documentar y pensar en tu arquitectura, claro, con medida (ve el punto anterior). En Google Images hay arquitecturas empresariales, no te fíes. Implementarlas te costará mucho tiempo y dinero (que es escaso en esta etapa). No importa mucho si visualmente no es bonita, si solo son palabras en una hoja o si quizás no hay un esquema formal de revisión como sucede en las corporaciones (mesa redonda, múltiples equipos, múltiples rondas de aprobaciones). Lo importante es que tengas un mapa que haga sentido con tu implementación y tu proyecto. Recuerda, no estamos pensando en una base de un millón o, inclusive, de 5000 usuarios, sino en una pequeña, pero muy pequeña, base de usuarios. Si tu arquitectura funciona para esa base, ¡lo demás es más fácil!

¿Tengo que tener un stack?

Al escuchar la palabra stack (véase, conjunto de frameworks y herramientas tecnológicas para resolver un problema), me recuerda allá por el año 2013, cuando el boom del Big Data y los frameworks para el front-end estaba en su auge, como Bootstrap, Django, Ruby on Rails, etc. MERN, MEAN, etc., son ejemplos de stacks. ¿Tengo que definir un stack? Respuesta corta: no. El uso de la palabra stack todavía se usa en círculos de aprendizaje, pero rara vez se aplica en el mundo real. Más raro aún es poner horas de desarrollo en definir uno para nuestra startup.

Al desarrollar el front-end y back-end de RecoImage, utilicé herramientas muy conocidas y usadas, nada fuera del otro mundo. Python y sus librerías para casi todos los procesos de back-end en la nube. Para el front-end tuve la opción de elegir entre React o Angular; decidí utilizar Angular, dado que tuve más exposición a lo largo de los años.

¿Y por qué esas opciones? ¿Por qué? Por preferencia y experiencia. Véase, no hice un proceso formal de selección, SWOT, pros y contras, investigación y análisis estadístico para elegir mis tecnologías, como muchos pensamos que se debe hacer al iniciar una startup: El underpin tecnologico que va a definir el IT de tu startup va mas enfocado a dos puntos:

• Que haga sentido con tu proyecto
• Que sea comodo para ti

No seamos unos trend chasers en el aspecto de los frameworks. Claro que hay frameworks y tecnologías que merecen que les demos un vistazo, pero al final del día, cuando tenemos que implementar nuestra idea, tenemos que guiarnos por lo que hace sentido para nosotros y que sabemos que nos va a ayudar a potenciar nuestra idea.

Optimizar ¿en esta etapa?

Cuando hablamos de optimización, siempre pensamos que es un proceso muy complicado y largo que no da frutos del todo. No hay suficiente tiempo para enfocarnos en cosas que parecen minúsculas. Así como también desarrollamos una arquitectura, digamos, en draft, también podemos dedicar un tiempo de desarrollo a optimizar.

La palabra «optimizar» tiene muchas connotaciones en diferentes contextos; aquí la definimos como todo aquello que puedas hacer mejor en el corto plazo.

Cuando implementé el front-end de RecoImage, en especial el Dashboard, tenía un pequeño dilema: cómo mostrarles a los usuarios sus proyectos de forma eficiente. Recordemos que, a pesar de que haya una free tier en muchos de los proveedores de la nube, no significa que no haya límites en nuestro uso.

Me imaginé a mi pequeña base de usuarios, digamos 10, utilizando mi aplicación. Si cada uno crea 10 proyectos por día, las cuentas son terroríficas a esta escala (1000 lecturas y 1000 escrituras por día), ¡y todo sin generar un centavo de ganancia! Claramente, había que optimizar este proceso. Al final, decidí utilizar una idea más sensata: Un refresh por log in, limite de proyectos, barra de busqueda y proceso de streaming. De esta forma mostramos los proyectos mas recientes y solo buscamos lo que ocupamos, de esta forma las cuentas se reducen mas.

Implementacion, la clave de todo

No bromeo cuando digo que la implementación lo es todo. Esta frase se ha repetido ad nauseam, pero por eso mismo es tan enfatizada que casi siempre perdemos el hilo de nuestro objetivo al momento de escucharla. Cuando inicié con mi primera idea, hace años, cometí el error de novato número uno: me enfoqué solo en el aspecto tecnológico. Recuerdo que, inclusive, me tomé una semana de capacitación acerca del sector de logística (la solución se enfocaba en el sector de transportes), pero no hubo implementación.

Implementar lo que sea que tengas en mente, que sirva para llevar y validar tu idea, es siempre más valioso que cualquier capacitación o decisión tecnológica que hagas. Implementa desde el día cero, crea, juega y experimenta. Todo tiene que tener una dirección, claro, pero no por eso implementar deja de ser menos importante.

Cuando desarrollé mi primer draft para RecoImage en cuestión de arquitectura y procesos, me imaginé tener que aplazar el desarrollo otra semana para dedicarme a documentar. Al final, mejor decidí implementar la primera versión de mi proceso, y vaya que me fue más valioso que estar en silencio en mi cuarto meditando sobre patrones de diseño.

Mi modelo de datos, el código, mi documentación y la implementación se vieron beneficiados. Esto surge porque, como dije arriba, el draft de la arquitectura (o inclusive si es una versión completa) es más como un mapa o una guía; la implementación es la que al final decide qué podemos cambiar, qué podemos optimizar, qué no funciona del todo y qué patrones podemos seguir. Al final, vas a ver un panorama más distinto si comparas tu proceso implementado con el que documentaste y, créeme, no hay nada de malo en eso.

En conclusion

Con esto, creo que tenemos una buena guía para comenzar a implementar nuestro proyecto. Como pudiste observar, lo complejo no es la tecnología (o su contraparte en código), sino esas decisiones blandas (soft skills) que, aunque no se traducen en código o tecnología, sí mejoran nuestra startup en muchos aspectos.