Entregar valor al usuario, sobre todo al iniciar un nuevo producto es uno de las cosas más importantes para mí dentro de mi Studio, y también para la mayoria de mis clientes, los cuales suelen ser startups, que buscan validar sus hipotesis lo mas rápido posible. Es aqui es donde hace 2 años vi en Meteor una herramienta para agilizar la entrega de funcionalidad al usuario final de manera rápida y sin comprometer la calidad de usabilidad del producto, su aproximacion a interfaces reactivas por defecto, aportan mucho valor al usuario, sin necesidad de pasar valiosas horas pensando que stack vas a usar para tu interface o configurando herramientas para empezar a desarrollar un frontend.

Su comunidad tambien me parecio una comunidad balanceada, desarrolladores, diseñadores aprendiendo a programar, pero aportando ideas de diseño y accesibilidad además de muchas personas encargadas de manejo de producto, hacian un ecosistema que se enriquece mas allá de lo técnico.

Sin embargo con el paso del tiempo, y a nivel interno, comenzamos a tener problemas de escalabilidad con algunas aplicaciones; con la adopción masiva de ReactJS y AngularJS en el frontend, el proyecto comenzo a tambalearse por la adopción de una arquitectura que no dependiera de Blaze, el sistema de rendereo de frontend que meteor maneja por defecto, y con esto, poco a poco nos empezamos a quedar sin “soporte” comunitario. La comunidad estaba ocupada solucionando problemas de integración con react, mientras nostros ya estabamos invertidos en Blaze. Estando entre la minoría de lo que sucedia en la comunidad llegamos al punto de pasar mas tiempo parchando el código para que fuera digno de poder aceptar nuevos features que usaban nuevas librerias, que haciendo features. Tomamos la decisión de comenzar a reescribir aplicaciones usando otras herramientas con un stack mas granular.

Pasamos de un framework todo en uno, a pasar días evaluando, cual framework de backend era el mejor, en el frontend, que sistema de templating, minificacion, usariamos y poniendonos al día (literalmente, en el mundo JS, cada dia sale the next big thing). Tomandonos el tiempo necesario en beneficio de la escalabilidad, fue así como hicimos a meteor un framework obsoleto en nuestro stack .

Hace algunos meses inicie dos nuevos repositorios para nuevos proyectos, haciendo un kickoff con el stack que veniamos manejando para proyectos corporativos, sin embargo han pasado meses y sin notarlo, la arquitectura esta sobre-optimizada para la etapa de vida en la que se encuentra el proyecto. cometiendo el error de no centrarme en funcionalidad que provea valor al usario. Por supuesto que creemos que lo que hacemos sera de utilidad, pero por el momento no puede ser usada.

A veces cuando se tiene un background tecnico, sin querer, podemos enfocar nuestros esfuerzos en hacer un producto de calidad, pero que no entrega valor de manera inmediata al cliente. En mi opinión esto tambien es quedarse en una zona de confort y hay que tener cuidado de no caer en ella, sobre todo cuando no tienes un sistema externo que te audite, como lo es algun inversionista, o algún cliente.

Por esto ultimo regrese a meteor, pero solo como herramienta de prototipado, en mi nuevo workflow, usar meteor es el equivalente a adquirir deuda técnica, pero que me ayuda a concentrarme en mis usuarios entregandoles una buena experiencia que de antemano se, será dificil de escalar, o que tiene fecha de expiración, pero que al menos me permitirá generar revenue, para financiar las optimizaciones futuras.