Escalando una Aplicación de React de 0 a Usuarios Brasileños

Una lección del mundo real sobre escalar una aplicación de JavaScript. Así que hace unos tres años, estaba en una posición muy difícil. Estaba nervioso. No podía concentrarme en nada. Miraba mi teléfono cada dos minutos porque tenía una decisión realmente importante que tomar. Decidí cambiar de trabajo, y tenía dos grandes ofertas sobre la mesa. Podía elegir ser un ingeniero de software senior bien remunerado en una empresa pública que tenía más de mil ingenieros, o podía elegir una posición de cofundador tecnológico con poco o ningún salario pero con acciones en la empresa y la oportunidad de construir el software desde cero.

Y me di cuenta de que me encanta construir cosas y ensuciarme las manos, y esto es un gran pero, siempre dejo los proyectos con solo las ventanas y puertas que faltan, como en el pequeño video aquí. Así que decidí que esta era la oportunidad perfecta para experimentar construyendo algo desde cero. Pero, ¿a qué accedí? ¿Cuál fue la idea que me hizo rechazar un salario lucrativo y la comodidad de un buen trabajo estable? Y la premisa básica era esta.

Vamos a la guerra con el botón de aplicar a trabajos. Este producto es solo para universidades, así que no estoy tratando de venderte nada. Pero no decimos, no te molestes. Decimos, no te molestes en aplicar a trabajos, haz networking y construye relaciones duraderas para que puedas ser recomendado para posiciones abiertas. Y hay todo tipo de empresas que hacen esto. Y los fundadores originales, Max y Marcus, eran estudiantes ellos mismos, y querían construir algo para estudiantes por estudiantes. Así que se reunieron una noche con un par de cervezas y dibujaron el flujo de Career OS, ese es el nombre de la empresa, en un trozo de papel. Y se ve algo así.

Recopilaron los correos electrónicos de alrededor de 30 tomadores de decisiones de escuelas con poder adquisitivo y les enviaron correos electrónicos en frío. Ahora, este es un ejemplo de un correo electrónico que enviaron hace dos años. Así que quiero enfatizar que en este punto no había startup. No había dinero. No había producto. Solo querían validar su idea. Si nadie respondía a su correo electrónico en frío, la idea era un fracaso. En cambio, aunque eran vacaciones de Navidad, recibieron alrededor de 10 respuestas. Entonces, y solo entonces, decidieron, OK, la idea valía la pena seguir adelante y se lanzaron a toda máquina a encontrar un cofundador técnico, yo, y recaudar dinero para construir una startup.

Ahora, el mayor error que noto que cometen los emprendedores tecnológicos es este. Tienen una idea para un negocio. Ahora, creo que esto nos ha pasado a todos. Así que si tienes una idea, probablemente harías esto. Comienzas a construir tu MVP e implementar un MVP. Y luego, para aquellos que construyen un MVP, van y lo validan con las personas equivocadas. Usualmente preguntan a sus amigos, preguntan a sus colegas de trabajo o incluso a sus padres. Y luego, con su MVP y la bendición de su madre, intentan recaudar dinero.

Ahora, siendo técnicos, van al único lugar del que han oído hablar, que es Y Combinator, donde usualmente son rechazados. Y cuando dicen que el 95 por ciento de las startups fallan, estas son las startups que usualmente fallan porque siguieron esta fórmula. Ahora, estos pilares tienen que ir de la mano de principio a fin, como hicimos con CareerOS. Validamos la idea sin gastar dinero, solo enviando correos electrónicos. Luego, cuando obtuvimos la respuesta, enviamos correos electrónicos a inversores que usualmente invierten en la industria de tecnología educativa superior. Y no intentamos obtener dinero. No propusimos nada transaccional. Solo medimos su interés. Solo les pedimos retroalimentación. Y solo para que lo sepas, a los inversores les encanta dar retroalimentación. Así que cada mes manteníamos a los inversores potenciales y clientes informados sobre nuestro trabajo y manteníamos a posibles contrataciones en el pipeline.

Ahora, en este correo electrónico, mencionamos que lo enviamos a todo tipo de personas como amigos, familia, mentores. En realidad, lo estábamos enviando a posibles inversores o posibles clientes. Así que nuestro canal de comunicación era nuestro principal canal de adquisición. Y después de seis semanas de hacer esto, teníamos nuestro primer MVP.

Así es como se veía. Entonces, la idea de CareerOS es que no solicitas tus trabajos, construyes relaciones para tus empresas soñadas y tienes una mayor oportunidad cuando se abre un trabajo. Con este MVP, conseguimos cuatro clientes de pago y recaudamos $800,000 en nuestra ronda de pre-semilla para poder contratar un equipo y simplemente hicimos todo al mismo tiempo.

Ahora, podría parecer imposible, pero este era yo hace 13 años en mi primer trabajo como programador. Al ver esto, podrías pensar, OK, ¿qué pasó? Bueno, tuve que trabajar con Angular 1.

Tuve que trabajar con React cuando tenía componentes de clase. En otra empresa, estaba usando V2 y Nuxt2. A veces hacía Laravel o PHP. Así que puedo decirte que al construir un producto y elegir un framework, tu mayor enemigo es el tiempo. En nuestra industria y ecosistema, cada semana aparece algo nuevo y no quieres quedarte atrás, o peor, ser incapaz de desarrollar algo porque tu stack está obsoleto.

Piensa en intentar integrar OpenAI SDK dentro de Angular 1. Es prácticamente imposible. Estamos tratando de contratar nuevos desarrolladores de Angular 1 en 2025. Estoy seguro de que puedes encontrar personas que sean capaces de programar en Angular 1, pero ¿quieren hacerlo? No lo creo. Así que al elegir el stack tecnológico para nuestra empresa, mi mayor temor era quedarme atrás. Así que hice algunas reglas para asegurarme de que siempre podamos actualizar nuestro stack o cambiarlo completamente. Así que no quería usar ninguna biblioteca de UI. Queremos construir nuestra propia biblioteca de componentes. No quería usar ninguna biblioteca de terceros, y no quería usar ninguna herramienta sin código.

También estaba profundamente impresionado por cómo la NASA y el mundo han logrado construir una estación espacial internacional. Así que la ISS fue construida usando diseño modular, y simplemente enviaron, durante 30 años, diferentes partes de la estación espacial. Así que al diseñar mi aplicación, quería trabajar de la misma manera. Cada módulo tenía directrices dedicadas, estructura de carpetas e interfaz. Pero para que funcionen, también necesitábamos un sistema de diseño y biblioteca de componentes. No quería repetir los errores de UI de mi pasado, y quería hacer todo reutilizable. Así que el primer archivo que creé en la aplicación fue en realidad variables CSS, tipografía SAS, mixins, para asegurar que siempre sigamos los mismos patrones de diseño.

Y por supuesto, cada componente tenía que tener una prueba unitaria, un storybook y pruebas de accesibilidad. Ahora, tenía tantas reglas establecidas cuando comencé, que olvidé esta famosa cita de Mike Tyson, como, todos tienen un plan hasta que reciben un puñetazo en la boca. Así que el primer golpe fue más bien una bofetada, pero nos dimos cuenta de que la regla de no usar aplicaciones de terceros era prácticamente imposible. Sucedió primero con la función de arrastrar y soltar de Arcamba. No importa cuánto lo intenté, simplemente no podía lograr que fuera perfecto. Y después de dos o tres días de codificación frustrante, me rendí e instalé React Beautiful DND.

Luego tuvimos que instalar Firebase para otros proyectos, luego analíticas. Luego necesitábamos manejar texto enriquecido, así que añadimos React Quill. Diferentes analíticas como June, Google Analytics, Customer IO, Sentry, React Loading para videos, React PDF cuando construimos el creador de currículums. Y como puedes ver, se salió de control. Ni siquiera cabe en la imagen. Actualmente tenemos más de 60 bibliotecas de terceros en la aplicación. Y con cada biblioteca que añadimos, nuestra capacidad para migrar y mantener la aplicación actualizada disminuyó, lo cual es algo que realmente temía.

Entonces, ¿qué hicimos? Bueno, para cada herramienta de terceros que añadimos, creamos un componente envoltorio o proxy que exponía una interfaz que usamos en diferentes partes de la aplicación. De esta manera, si alguna vez necesitábamos reemplazar Mixpanel por otra cosa, solo teníamos que cambiarlo en este componente envoltorio y hacer que la nueva biblioteca usara la misma interfaz que la antigua. Fuimos un paso más allá. En lugar de llamar a diferentes eventos en nuestro producto, encapsulamos todas nuestras analíticas en un módulo de analíticas. De esta manera, si alguna vez necesitamos añadir otra biblioteca de seguimiento para, digamos, eventos de Algolia, simplemente los añadimos aquí en el hook de analíticas de usuario y se aplican automáticamente en toda la aplicación.

Y también lo hizo súper, súper fácil eliminar módulos también. Ahora, todas nuestras bibliotecas de terceros, alrededor de 60, están encapsuladas en su propio módulo envoltorio. Y esto también ayuda con el proceso de construcción porque si importas una tercera biblioteca desde Node modules en toda tu aplicación, podría aumentar las posibilidades de ser añadida dos veces dentro de la construcción.

Ahora, otro golpe que recibimos fue con nuestra biblioteca de componentes y sistema de diseño. Un año en nuestro inicio de vida, comenzamos nuestro tercer proyecto. Y luego decidimos, está bien, inicialmente teníamos todos nuestros componentes en la misma carpeta raíz. Y luego decidimos, está bien, vamos a moverlo a un paquete npm. Pensamos que iba a ser fácil, pero estábamos completamente equivocados. Teníamos alrededor de 50 componentes en ese momento. Y decidimos simplemente empezar pequeño y comenzamos con el botón. Pero después de mover todo y hacer que el componente del botón funcionara para nuestra biblioteca de componentes, pensamos, está bien, ahora la parte difícil ha terminado.

Quedan 49 componentes más. Es una aventura fácil, 20 minutos. Vamos. La realidad fue otro golpe. Pensamos que manteníamos todos nuestros componentes tontos, pero desafortunadamente, mucha lógica relacionada con el proyecto se infiltró dentro de los componentes, como la navegación basada en el enrutador, valores relacionados con el estado o incluso llamadas a la API en algunos casos extremos. Y también tuvimos una condición de carrera. Para cuando movimos el componente dentro de una biblioteca de componentes, en la carpeta, podría haber cambiado ya en el proyecto principal. Así que la velocidad del equipo era tan rápida que nuestra profundidad técnica nos estaba golpeando fuerte.

Así que abordamos esto en tres etapas. Figma como fuente de verdad, mover componentes uno por uno y asignar un líder de proyecto que se encargara de distribuir el trabajo, pero también revisor obligatorio para no permitir que la carpeta de componentes dentro del proyecto se siga trabajando. Y luego mover storybook CICD y crear un pipeline CICD que mantenga la aplicación principal y la biblioteca sincronizadas. Así que si hay algo que cambiaría, si pudiera volver en el tiempo, haría el paquete npm desde el principio y no esperaría hasta que fuera necesario.

Otro golpe que recibí fue un serio error de implementación que cometimos. Comenzamos a notar un año después de nuestro inicio que DevTools en el navegador comenzaba a volverse más y más lento. Eventualmente, se volvió inutilizable. Ahora, la razón de esto fue que notamos que los estilos se estaban cargando mil veces para cada componente de los modelos que estábamos usando. Así que todo estaba bien en la construcción final porque tenía tree shaking, pero en el modo de desarrollo, no funcionaba. Ahora, asumí que el problema era con la importación de SAS como datos adicionales dentro de nuestra configuración de Vite.

Y al principio, pensé que era porque estábamos usando la palabra clave import y no la palabra clave use. Así que lo cambié. Esto lo hizo mejor y más limpio. Y ahora podía observar qué archivos se estaban importando una y otra vez. Así que noté que eran solo nuestras reglas raíz de CSS, como nuestras variables. Y mirando en los archivos, me di cuenta de que puse estos en la tipografía dentro de la utilidad, que son archivos SAS. Así que también agregué allí los archivos CSS.

Así que si no lo sabes, cuando usas datos adicionales, solo necesitas tener datos relacionados con SAS dentro de datos adicionales. Así que, por ejemplo, en variable CSS, debería ser solo variables SAS, funciones SAS y mixins SAS. Y yo, porque añadí CSS, se añadió para cada componente el CSS en la parte superior del componente. Así que me puse a trabajar. Moví todos los archivos raíz a un archivo CSS global que importé en index.html. Y el problema desapareció. Y para hacer las cosas aún más embarazosas, esta única solución nos ahorró como 200K de nuestra construcción final de JavaScript.

Ahora, sobre el tamaño del paquete, seguimos añadiendo características. Así que nuestro paquete seguía aumentando y el rendimiento se estaba degradando. Así que decidimos usar la carga diferida de nuestras raíces principales usando React.lazy, así. Entonces, lo que sucede cuando haces esto es que si vas a una página, cargará el código relacionado con esa página solo cuando hagas clic en la navegación. Pero el problema fue que tan pronto como hicimos esto, en producción comenzamos a recibir algunos errores, que es el error de fallo al importar el módulo dinámico. Ahora, esto estaba sucediendo porque cada vez que implementábamos, si hay personas usando la aplicación y hacen clic en la navegación, nuestro proceso de implementación elimina el hash antiguo que la implementación está usando para propósitos de ruptura de caché y lo actualiza con uno nuevo.

Y cuando el usuario hace clic en la raíz, intenta obtener el hash antiguo en el servidor, pero ya no está allí. Ahora, Vite tiene un evento de error de precarga al que puedes escuchar globalmente. Y cuando esto sucede, simplemente recarga la página y esto funcionó el 99% del tiempo. Pero para un molesto 1%, estaban usando navegadores antiguos o Safari móvil por alguna razón, los dejaba en un bucle infinito. Así que exploramos diferentes soluciones. Y por supuesto, la más segura era no eliminar el hash antiguo del disco y mantener una o dos versiones en prone para que esto no suceda. Y esto, nuevamente, funcionó el 99% del tiempo, pero cuando teníamos cambios de API que rompían, también hacía que la aplicación fallara, lo cual tampoco queríamos. Y eventualmente, llegamos a nuestra solución final donde manteníamos ambas versiones del hash, pero en lugar de ser un hash aleatorio que Vite genera, usamos la versión del paquete de nuestras aplicaciones como el número de versión, como el hash.

Y luego, cuando hacemos un despliegue, tenemos un service worker que realmente se ejecuta en segundo plano, verifica si hay una nueva versión de la API, y cada vez que hay una nueva versión de la API, actualiza los source maps del manifiesto interno del usuario. Así que, en general, han pasado más de dos años. Estamos usando el último React, el último Vite, y el último TanSec. Y estamos bastante contentos de haber mantenido la profundidad técnica lo más cercana a cero posible mientras avanzamos muy, muy rápido en la construcción de un producto orientado al consumidor. Nuestra aplicación es muy buena ahora, si soy honesto, pero hace un año, estábamos inundados de errores, ya sean funcionales o visuales. Nuestra aplicación se rompía todos los días, especialmente durante las llamadas de ventas. Conteníamos la respiración para que no se rompiera, y tristemente, usualmente lo hacía. Se puso tan mal que todos tenían una broma corriente de que nuestra aplicación solo funcionaba el 60% del tiempo.

Entonces, ¿qué hicimos? Bueno, primero implementamos una política de no ventanas rotas. Así que si no lo sabes, la teoría de la ventana rota establece que si un vecindario tiene una ventana rota, normaliza el crimen y aumenta las tasas de criminalidad. Y sucede lo mismo en las aplicaciones. Si ya tienes errores en la aplicación, simplemente los acumulas en la lista de pendientes, creando una normalidad de que la aplicación tenga errores y se rompa. Dijimos basta. Y todos los miércoles durante todo el verano, dedicamos seis horas al día a la eliminación de errores, una competencia donde tomamos todos los errores de la lista de pendientes y los corregimos, desde errores de funcionalidad hasta errores visuales e incluso pequeñas mejoras y animaciones encantadoras.

Ahora, siendo el verano con las Olimpiadas, lo hicimos una competencia con medallas y otorgamos tarjetas de regalo de Amazon a los ganadores. En realidad, me tomó dos semanas encontrar la solución donde estoy primero. Así que fue un gran éxito para limpiar nuestra aplicación. Y como puedes ver, pero eso fue solo la mitad de la batalla. Queríamos asegurarnos de que las funcionalidades no se infiltraran en nuestros productos. Así que implementamos una forma diferente de trabajar. Nuestra aplicación front-end estaba alojada en Netlify. Y Netlify tiene la capacidad de crear vistas previas de despliegue. Y, por supuesto, puedes... Vercel tiene lo mismo y otros proveedores de alojamiento hacen lo mismo. Pero usamos estas vistas previas para hacer aceptación de diseño, pruebas de control de calidad y aceptación del producto antes de que cualquier cosa se fusione en main. Luego creamos un proceso de lanzamiento bastante bueno donde cada vez que fusionas algo, tenemos una acción de GitHub que toma el título del PR, determina la versión semántica, si es un cambio mayor, menor o de ruptura. Y luego agrega esto a nuestro borrador de lanzamiento en GitHub.

Así que a la izquierda, puedes ver todo lo que no se está lanzando porque no tenemos CI CD. Presionamos un botón manualmente. Así que si quieres leer más sobre este proceso de lanzamiento, tengo un tutorial completo en mi blog, nechudan.dev.

Pero finalmente, hicimos una fuerte recomendación en cada tema para usar Coursor. Y de esa manera, creamos reglas de Coursor que contienen cómo escribir nuestro SAS, cómo escribir nuestro HTML, usando sintaxis BEM para clases, cómo escribir nuestros tipos, React, nuestras pruebas. Ahora esto facilitó a los desarrolladores de back-end ingresar a la base de código y usar Coursor y hacer cambios si lo necesitan. Y para que los nuevos integrantes se incorporen más rápido.

Luego, en el propio PR, todos tienen que incluir lo que ha cambiado y agregar videos con el antes y después para facilitar las pruebas y la aceptación del producto. Ahora, avanzando rápidamente en solo dos años, vendimos nuestro producto a más de 50 universidades en todo el mundo, incluyendo grandes nombres como Oxford, Berkley, Stanford. Y con las mejores prácticas en su lugar, construimos este producto en solo dos años.