Firstleaf
Lead Engineer, luego Engineering Manager · 2019–2026
Firstleaf vende vino por suscripción. Estuve casi siete años: tres como lead engineer del storefront y cuatro como engineering manager de un equipo cross-funcional, en los que convertimos una base de 1,5 millones de vinos en un canal de búsqueda orgánica.
- páginas de vinos, renderizadas on demand
- 1,5 M
- páginas temáticas, publicadas por etapas
- ~50 mil
- en Lighthouse después de rehacer el storefront
- 90+
- personas en mi equipo como engineering manager
- 6
Un solo storefront, en cualquier pantalla
Cuando llegué, el storefront no estaba pensado para mobile, y la tienda y el checkout de suscripción se veían y se comportaban como dos sitios distintos. Rehacerlos como una sola experiencia consistente y mobile-first fue mi primer gran proyecto.
Después fuimos por la velocidad. Amplitude y Datadog mostraban por dónde iba la gente y dónde esperaba; Lighthouse mostraba por qué. Trabajamos los flujos que más importaban hasta que todos los puntajes de Lighthouse quedaron por encima de 90.
Una librería de componentes para devs y diseño
Construí la librería de componentes compartida que usaba todo el equipo de frontend —más de diez devs— y los tres diseñadores que trabajaban con ellos. Tres decisiones la mantuvieron sana:
- Storybook como terreno común. Diseño podía ver cómo se renderizaba cada componente, en cada estado, e iterar ahí sin esperar a que se armara una página.
- Base contra instancia. Cambiar un componente base es un cambio de la librería, hecho a propósito y para todos; un ajuste que necesita una sola página queda en esa página. Separar las dos cosas evitó que los parches puntuales se filtraran por todo el sitio.
- Composición. Los botones primary, secondary y tertiary se construyen sobre el mismo botón base, así que un fix se hace una vez y llega a todas las variantes.
Previews a demanda
Junto con DevOps armé GitHub Actions para buildear, testear y deployar a AWS. Encima construimos una herramienta chica: comentás /deploy en un pull request y esa rama se buildea y se deploya en su propio preview en S3.
Y creció desde ahí. Las ramas de la API también tuvieron preview, una rama de frontend se podía combinar con una de backend, y cada preview podía arrancar con una base de datos limpia o con un dataset acotado.
El directorio de vinos
Como engineering manager lideré la construcción de un directorio de vinos pensado para traer tráfico de búsqueda orgánica. El punto de partida era una base de referencia externa de 1,5 millones de vinos. Usamos AI para limpiarla y completar atributos como región y varietal. Matchearla con el catálogo propio de Firstleaf, de unos 10.000 vinos, fue la parte fácil, porque la marca ya venía en los datos.
Cada vino tuvo su página. Lo más interesante fueron las páginas temáticas: a partir de una plantilla como “vinos que maridan con {comida}”, la AI escribía un borrador, una persona lo revisaba y la página salía publicada con un grid de vinos relevantes y su entrada en el sitemap. Esos grids son los que hicieron funcionar el directorio. Son links internos que unen páginas temáticas con páginas de vinos, y eso ayuda a la gente a navegar y a los buscadores a indexar.
Todo se servía con server-side rendering desde templates de Rails, on demand y con caché. Un build estático de 1,5 millones de páginas hubiera sido eterno; renderizar a demanda hacía que una página no costara nada hasta que alguien, o un crawler, la pidiera.
Publicar era la parte delicada. Un sitio que de repente crece en decenas de miles de páginas puede parecerle spam a Google, así que publicamos por etapas: 10 páginas, después 100, 500, 5.000 y 40.000. Entre una etapa y otra esperábamos un par de semanas y revisábamos Search Console antes de seguir, y seguíamos los rankings con Ahrefs.
Cuando me fui había unas 50.000 páginas temáticas, que linkeaban a unos 400.000 de los 1,5 millones de vinos. Al tercer mes, el directorio ya traía unas diez conversiones por mes desde búsqueda orgánica: números tempranos, para un canal que tarda en madurar y no tiene costo de adquisición.
Liderar el equipo
Como lead engineer lideré un equipo de cinco. Mis últimos cuatro años fui engineering manager de un equipo cross-funcional de seis —tres devs de frontend, uno de backend, QA y un diseñador— junto a nuestro product manager. Hacía discovery con negocio y operaciones, convertía pedidos en roadmaps y reportaba resultados a la dirección y al board.
También llevé las contrataciones del equipo. Diseñé el take-home —encontrar los bugs en un repo chico con un grid de vinos y mejorarlo, parecido al trabajo real— e hice las entrevistas técnicas y de cultural fit: unos veinte candidatos, cuatro o cinco contrataciones.