Saltar al contenido
Sebastian.Gebhardt
Volver a Cartas17 de agosto de 20266 min · ensayoThe Retail Brief · Nº 005 · RETAIL & AI

Build vs Buy en la era de la IA.

«Tu página es pésima», me dijo un cliente. Tenía razón. Y arreglarlo me cambió cómo decidimos qué software compramos.

"Tu página es pésima."

Me lo dijo un cliente. Textual. Y tenía razón.

Hace tres años eso habría abierto un proceso: levantar requerimientos, cotizar plataformas, elegir integrador, seis meses. Esta vez relanzamos thelabstore.cl y en dos semanas el ecommerce pasó de 15% a 35% del mix de ventas.

No lo cuento como logro. Lo cuento porque me obligó a revisar una regla que yo daba por cerrada.

La regla que dábamos por cerrada

Durante veinte años, build vs buy fue una pregunta sobre el costo de construir. ¿Tengo el equipo? ¿Cuánto demora? ¿Cuánto cuesta mantenerlo?

Y en una empresa de retail de tamaño medio la respuesta era casi siempre la misma: compra. Obvio. No eres una empresa de software.

La IA no cambió la respuesta. Cambió cuál era la pregunta.

Si construir un reemplazo funcional toma cinco días — y lo hice, repliqué un SaaS completo en cinco — el costo de construir dejó de ser lo que decide. Cuando la variable que decidía se abarata, el cuello de botella se muda. En nuestro caso se mudó a la adopción: cuántas personas de un equipo lean pueden operar bien lo que sea que tengas.

Ya no es "¿lo construyo o lo compro?". Es "¿esto lo va a operar mi equipo, o va a ser una licencia que pagamos y nadie abre?".

Cinco días no es lo que suena

Un detalle importante para no leer mal esta historia.

Cinco días no fue "construí un producto". Fue "construí lo que nosotros usábamos de ese producto". Un SaaS maduro carga diez años de casos borde, permisos, integraciones y clientes que no se parecen a mí. Nosotros necesitábamos una fracción.

Esa fracción es todo el punto. Construir se volvió viable no porque la IA escriba software de nivel enterprise, sino porque la mayor parte del valor de un SaaS, para un cliente específico, vive en una porción chica de su superficie. Y esa porción hoy se construye en días.

Hoy una parte creciente de nuestro software crítico se construye adentro: IRIS opera las tiendas, Cerebro vigila los precios, Draper decide qué ofrecerle a cada cliente, Meridian mide el marketing, Delphine ayuda a comprar, Octavius Flow opera los marketplaces, Cifra consolida la caja, Chispeza contrata y entrena vendedores.

Nueve sistemas. Ninguno se compró.

Lo que sí compramos

Sería deshonesto vender esto como "no compramos nada".

SAP corre el ERP. BigQuery guarda los datos. Meridian está construido sobre el Meridian de Google, no desde cero — nuestro trabajo fue el pipeline por marca, los ocho modelos independientes y el reentrenamiento semanal, no el motor bayesiano. Los marketplaces sobre los que opera Octavius Flow son de MercadoLibre, Falabella, Paris y Ripley.

La regla que sacamos, y que creo que generaliza:

Compra la infraestructura. Construye la decisión.

Nadie debería escribir su propia base de datos, su propio ERP ni su propio motor de MMM. Pero la lógica que decide qué precio poner, a qué cliente hablarle, qué zapato comprar — esa lógica es el negocio. Comprarla es comprar el criterio de otro y esperar que se parezca al tuyo.

La objeción del mantenimiento

Acá es donde alguien siempre levanta la mano, con razón. Un SaaS te cobra por no pensar en actualizaciones, seguridad, uptime y en la persona que se fue. Nueve sistemas internos son nueve cosas que alguien tiene que mantener, y ese costo no aparece en la semana del lanzamiento.

Esperaba que doliera más de lo que duele. Y creo que la razón es exactamente la que hace que valga la pena construir: son hechos a medida.

Un SaaS carga diez años de superficie construida para clientes que no somos nosotros, y esa superficie alguien la mantiene — la pagas en la licencia, aunque uses el 15%. Lo nuestro hace lo que necesitamos y nada más. Menos superficie es menos que mantener, y es también menos que entender cuando algo se rompe a las once de la noche.

No es gratis, y no voy a decir que lo sea. Pero la intuición de que nueve sistemas internos son nueve veces el problema resultó falsa, y no porque seamos rápidos: es que ninguno carga peso que no usamos.

Cómo lo decidimos hoy

Cuatro preguntas, en este orden.

¿Esto es infraestructura o es criterio? La infraestructura se compra; el criterio se construye.

¿Dónde ya trabaja la gente que lo va a usar? Si la respuesta es un canal que el SaaS no soporta — WhatsApp, en nuestro caso — comprar significa comprar también un problema de adopción que no aparece en la demo.

¿Qué fracción del producto necesitamos de verdad? Si es el 15% de su superficie, el precio del 100% dejó de ser una ganga.

¿Podemos medir si funciona? Esta descalifica en ambas direcciones. Un sistema propio que no puede probar su efecto es tan malo como una licencia que nadie puede evaluar.

Esto no nos convierte en una empresa de software

Y no quiero que lo sea. Somos un grupo de retail multimarca. El software que construimos existe para operar tiendas mejor, no para venderse.

Lo que cambió es más chico. Dejamos de aceptar que "no somos una empresa de tecnología" fuera razón suficiente para comprar.

Durante veinte años lo fue. Hoy hay que justificarlo, caso por caso.

Si tuvieras que defender hoy tu última compra de software, ¿la defenderías por lo que hace, o por lo que costaba construirla en 2019?