En Muni, no toda la tecnología que usábamos y ofrecíamos a nuestros usuarios era desarrollada internamente, por dar un ejemplo, la gran mayoría de nuestras necesidades de data y eventos para marketing eran suplidas por Segment, Amplitude, Stitch, Snowflake, y Metabase, incluso, algunos features, o primeros experimentos de alguna funcionalidad, fueron simplemente construidos utilizando servicios como zapier, typeform, y herramientas de google como Sheets, Data Studio, o Appsheet.

Construir software es algo MUY costoso, en tiempo, en dinero, y una vez decides construir algo in-house, debes tener presente que muy probablemente vas a tener que mantenerlo hasta el fin de los tiempos.

Es muy importante, para cualquier empresa de tecnología, hacerse la pregunta “should I buy or should I build?”.

Tomar esta decisión no es trivial, y como todo en el desarrollo de software (y en la vida), nada es gratis, siempre habrán tradeoffs a considerar, pero, el criterio personal que tiendo a usar para tomar esta decisión es:

¿Lo que necesitas es una funcionalidad o producto clave para el negocio, y tienes o quieres tener un equipo interno dedicado para su construcción y mantenimiento?, entonces construyelo, de lo contrario, cómpralo, y entrega su construcción y mantenimiento a quien tiene ese feature o producto como core de su negocio.

Sin más preámbulo doy una visión general de los productos principales que si construimos internamente y sobre que tecnologías.

El primero de nuestros productos era la aplicación para los líderes de comunidad, donde ellos pudieran gestionar sus pedidos, ver sus ganancias, compartir el catálogo con sus clientes, etc…

Esta aplicación la construimos “nativa”, con Kotlin para Android, y Swift para iOS.

El segundo de nuestros productos era el catálogo de productos. Esta era una aplicación web, construida sobre React, donde los clientes de los líderes de comunidad podían explorar los productos disponibles y hacer sus pedidos directamente a su líder.

La decisión de hacer esta aplicación web, y no móvil, fue tomada en base a facilitar la compra por parte de los clientes. No debes descargar nada, solo abres un link, y ya puedes hacer tu pedido.

El tercer y último producto core de Muni, era de hecho una colección de productos más pequeños y de uso interno para el control de órdenes, gestiones de quejas, devoluciones, empaque, despacho y seguimiento de pedidos.

Estos productos “operativos”, estaban construidos bajo el esquema de “micro frontends”, con una aplicación “padre” hecha sobre Django y que agrupaba a las demás, que en su mayoría también estaban hechas en React.

La única excepción fue la aplicación de entrega de pedidos que usaban los transportistas. La cual era un bot de whatsapp conectado con nuestro backend.

Ya que menciono nuestro backend, este estaba construido sobre una arquitectura de microservicios, enfocados en áreas importante de nuestro negocio como lo son los usuarios o los carritos de compra. En su mayoría, todos estaban construidos en Laravel, NestJS, o Django, y todos usaban bases de datos relacionales MySQL, excepto por uno de ellos, que usaba la real time database de firebase.

Por último nuestra infraestructura se encontraba en AWS, toda gestionada a través de terraform, y usando como servicios principales, ECS (Fargate), ECR, EC2, S3, SNS, SQS, Route53, y Batch.

Cabe mencionar que todo nuestro código vivía en Github y usábamos Github actions para nuestros pipelines de CI/CD, al igual que para la ejecución de tareas automatizadas, como por ejemplo, la copia de bases de datos de un ambiente a otro.