Build vs Buy sin drama: cuándo desarrollar y cuándo comprar (sin morir en el intento)

Lunes, 9:07 am. Ventas ya prometió una “integración rapidita” para cerrar el deal. El CEO pregunta cuánto te tardas. El CFO pregunta cuánto cuesta. Tú abres el backlog, ves el stack medio parchado, y piensas: “si lo construyo, me tardo; si lo compro, igual me tardo… pero con tarjeta corporativa y contrato”.

Ese es el Build vs Buy de verdad: no es debate de café, es supervivencia con deadline.

Qué te llevas

• Cómo decidir cuándo conviene desarrollar y cuándo conviene comprar sin caer en el “porque sí”.
• Criterios que sí mueven la aguja: time-to-value, costo total (TCO), riesgo, compliance, lock-in y mantenimiento.
• Un modelo simple para bajarlo a tierra: matriz de decisión + cálculo rápido de costo.
• Errores comunes que cuestan meses (o renuncias) y cómo esquivarlos.

Contexto práctico (lo que pasa en la vida real)

En México y LatAm, el dilema trae dos ingredientes extra que casi nadie pone en el spreadsheet:

1. Presupuesto con fricción. “Sí hay lana, pero no hay proceso”, o “hay proceso, pero el comité compra en 8 semanas”. Entonces haces un MVP interno “mientras”… y el “mientras” se vuelve core en production.

2. Operación con improvisación. El SAT cambia reglas, el banco pide formatos raros, el proveedor te deja en visto. Y ahí sigues: deploys tarde, WhatsApp de soporte y el Excel “temporal” que ya es BI.

La decisión decente no es “build siempre” ni “buy siempre”. Es: qué te da valor pronto sin hipotecarte a futuro.

Paso a paso: guía para decidir Build vs Buy

1) Define el trabajo real (no el “feature”)

Antes de hablar de herramientas, escribe una frase tipo:

• “Necesitamos emitir facturas CFDI 4.0 sin que contabilidad nos odie.”
• “Necesitamos rastrear leads y forecast para que ventas deje de pelear con finanzas.”
• “Necesitamos control de accesos y auditoría para pasar compliance con el cliente enterprise.”

Si no lo puedes decir así, todavía no es decisión técnica; es confusión de negocio.

Decisión con filo: si el problema está borroso, compra algo estándar o arma un prototipo barato. Construir sobre ambigüedad es garantía de re-trabajo.

2) ¿Es core o commodity? (pero neta)

Regla útil: core es lo que te diferencia y paga la nómina. Commodity es lo que necesitas para operar sin pena.

• Core (suele valer build): motor de pricing, matching, logística propia, antifraude con señales únicas, recomendación amarrada a tu data.
• Commodity (suele valer buy): nómina, contabilidad, CRM básico, helpdesk, analytics estándar, auth, e-sign.

Trampa típica: “nuestro proceso es único”. A veces es único porque está roto desde 2017.

Decisión práctica: si hay equivalentes maduros en el mercado y tu ventaja no viene de ahí, inclínate a buy.

3) Calcula el Time-to-Value (TTV) con calendario real

Dos estimaciones brutales (cero optimismo):

• Build: diseño + dev + QA + seguridad + docs + soporte + monitoreo + iteraciones + onboarding.
• Buy: selección + procurement + legal + implementación + migración + training + integraciones.

En México, el buy se atora por contratos/pagos; el build se rompe por prioridades cambiantes.

Regla de guerra: si el negocio necesita valor en menos de 6–8 semanas, build solo funciona si ya tienes equipo y base lista. Si no, compra o recorta alcance.

4) Estima el costo total (TCO), no el “licencia vs dev”

TCO = dinero + tiempo + riesgo.

Build incluye:

• Sueldos (y rotación: cuando se va el que “sabía todo”)
• Infra, observabilidad, alertas, backups
• Mantenimiento (bugs, upgrades, refactors)
• On-call y soporte (sí, alguien lo va a atender)

Buy incluye:

• Licencia + add-ons + incremento por usuarios
• Implementación/consultoría
• Integraciones (API, webhooks, ETL)
• Lock-in: costos de salida y migración

Ejemplo rápido, bien común:

• Build: 2 devs x 3 meses (full focus) + 1 QA parcial + 1 PM parcial. Aunque “ya están en nómina”, estás quemando capacidad que podrías meter a producto.
• Buy: 1,500–5,000 USD/mes + 2–4 semanas de implementación + training.

Decisión práctica: si tu build se va a volver un mini-producto interno con roadmap, ya no lo compares contra “una licencia”; compáralo contra “un proveedor que vive de eso”.

5) Riesgo operativo: ¿quién paga cuando truena?

Preguntas incómodas (las que salen cuando tu laptop vieja ya está a 3% y el jefe pide el cambio “para ayer”):

• Si se cae a las 2 am, ¿quién recibe la llamada? ¿tú o el vendor?
• ¿Hay SLA real o es “best effort”? ¿hay penalizaciones?
• ¿Qué tan fácil es diagnosticar? (logs, auditoría, soporte)

Buy suele ganar cuando:

• El costo de un outage es alto (dinero, reputación, multas)
• Necesitas SLA, soporte 24/7, compliance

Build puede ganar cuando:

• Puedes aislar el componente y hacer rollback sin tumbar todo
• No es crítico y el impacto está contenido

6) Compliance y seguridad sin autoengañarte

Si hay datos sensibles (PII), tarjetas, salud, nómina, o clientes enterprise pidiendo evidencia, aquí no hay magia.

Comprar puede ser más rápido si el proveedor ya trae certificaciones. Pero ojo: también hay vendors que “prometen” y su security posture es puro PDF bonito.

Checklist express:

• SSO/SAML, MFA
• Auditoría (quién hizo qué y cuándo)
• Exportación de datos (sí, para salir)
• Data residency si aplica

7) Lock-in: la pregunta brutal

“¿Puedo salir en 30 días?”

No siempre necesitas poder salir en 30 días… pero sí saber el precio.

• Si compras: ¿cómo exportas datos? ¿formato? ¿API completa o limitada? ¿cuánto cuesta la salida?
• Si construyes: ¿qué tan amarrado está a tu stack? ¿solo corre en “la laptop del senior”? ¿hay documentación real?

Decisión práctica: si el lock-in es inevitable, negocia desde el inicio: cláusulas, descuentos multi-año, límites de incremento, y acceso a data.

8) Usa una matriz simple (puntos) y decide

Puntaje 1–5 por criterio y sumas. No es ciencia exacta; es para alinear a todos y bajar la opinología.

Criterios:

• Diferenciación (core)
• Urgencia (TTV)
• Riesgo operativo
• Compliance
• Costo a 12–24 meses
• Capacidad del equipo (skills y foco)
• Lock-in tolerable

Interpretación rápida:

• Más urgencia + más riesgo + commodity → Buy
• Más diferenciación + control + data/algoritmo propio → Build
• Si queda empate → hybrid (compra base y construye encima)

Patrón que funciona: Hybrid (compra el 80%, construye el 20% que te diferencia)

Este patrón salva startups y también empresas medianas cuando el presupuesto no da para “hacerlo todo bien” y aún así hay que sacar el jale.

• Compras lo estándar (auth, billing, CRM, helpdesk, analytics base).
• Construyes capas donde sí ganas: reglas de negocio, automatizaciones, dashboards específicos, integraciones con sistemas raros.

Ejemplos aterrizados:

1. Facturación en México

   • Buy: PAC/servicio de timbrado y librerías maduras.
   • Build: tu lógica de negocio (catálogos, conciliación, flujos de cobranza).
   • Por qué: el SAT no perdona y mantener un parser de XML interno es castigo.

2. CRM para ventas B2B

   • Buy: HubSpot/Pipedrive/Salesforce (según tamaño).
   • Build: integración con pricing, inventario, onboarding de clientes, alertas.
   • Por qué: el CRM es bueno para pipeline; tu ventaja está en cómo vendes y entregas.

3. Atención al cliente

   • Buy: Zendesk/Freshdesk/Intercom.
   • Build: bots/triage, enrichment con data interna, automatización de refunds.
   • Por qué: el vendor te da canal y reporting; tú pones la inteligencia de tu operación.

Screenshots sugeridos

• Tabla/matriz de decisión con criterios y puntajes (Google Sheets/Notion).
• Diagrama simple de arquitectura hybrid: vendor + tu servicio + data warehouse.
• Captura de un cost model con TCO a 12 y 24 meses.
• Checklist de seguridad para evaluar un SaaS (SSO, auditoría, export).

Errores comunes + solución (los que sí rompen equipos)

Error 1: “Construimos rápido” y se vuelve sistema core sin mantenimiento

Síntoma: el MVP vive 18 meses, nadie se atreve a tocarlo, y cada cambio rompe algo.

Solución: si construyes, presupuestar desde el día 1:

• Observabilidad mínima (logs estructurados + métricas)
• Backups y plan de restore
• Documentación de “cómo corre”
• Dueño claro del componente

Error 2: Comprar y customizar tanto que ya no es SaaS

Síntoma: 30 campos custom, 12 workflows raros, y cada upgrade duele.

Solución: adapta tu proceso al 80% del producto. Customiza solo donde hay ROI claro. Si necesitas re-escribirlo todo, quizá debiste construir.

Error 3: Ignorar procurement/legal hasta el final

Síntoma: ya integraste el vendor en staging, pero legal tarda 6 semanas; el deal se enfría.

Solución: corre procurement en paralelo desde el shortlist. Ten un paquete listo: términos, DPA y security review.

Error 4: Comparar licencia vs dev como si fueran equivalentes

Síntoma: “sale más barato construir” porque no cuentan on-call, QA, soporte y rotación.

Solución: usa TCO a 12–24 meses y pon costo de oportunidad: ¿qué feature no vas a deployar por estar construyendo esto?

Error 5: No planear la salida (exit plan)

Síntoma: el vendor sube precios o cambia condiciones y estás amarrado.

Solución: define desde el inicio:

• formato de export de datos
• frecuencia de respaldos
• quién tiene credenciales y ownership
• criterio de “cuándo migramos”

Checklist final (para decidir en una junta sin gritos)

• El problema está definido como job to be done y tiene dueño.
• Ya sabemos si esto es core o commodity (y por qué).
• Estimamos TTV real para build y buy (incluyendo legal/procurement).
• Calculamos TCO a 12–24 meses (incluye soporte y mantenimiento).
• Evaluamos riesgo operativo (SLA, on-call, rollback).
• Seguridad/compliance revisado (SSO, auditoría, data export).
• Lock-in entendido y negociado (costos de salida y aumentos).
• Hay plan hybrid si aplica (comprar base + construir diferenciador).
• Se documentó la decisión (una página) para no re-litigarlo cada mes.

FAQ

1) ¿Regla rápida para decidir build vs buy?

Si es commodity y necesitas valor pronto, compra. Si es core y te diferencia con data/proceso propio, construye. Si no estás seguro, hybrid.

2) ¿Qué hago si el CFO solo ve el precio mensual del SaaS?

Llévale TCO y costo de oportunidad: “si construimos esto, dejamos de entregar X que genera ingresos”. Súmale el costo de fallas: outages, multas, churn.

3) ¿Qué pasa si el equipo quiere construir por orgullo técnico?

Pon un criterio duro: “¿esto nos diferencia y genera dinero?” Si la respuesta es no, es hobby. Y los hobbies no van en production con deadline.

4) ¿Cuándo sí conviene construir aunque exista un SaaS?

Cuando el SaaS no cubre tu caso crítico (o lo cubre con puros hacks), cuando la latencia/costo por uso te mata, cuando necesitas control fino por compliance, o cuando el algoritmo es tu ventaja.

5) ¿Cómo evito que comprar se vuelva dependencia eterna?

Negocia salida desde el día 1 (export, backups, límites de incremento), evita customizaciones excesivas, y encapsula integraciones: que tu sistema hable con una capa propia, no directo a todo.

Siguiente episodio

Ya decidiste build o buy… y luego llega lo bueno: migrar sin tumbar la operación.

Estrategias de migración, rollbacks, feature flags y cómo evitar el “big bang” que termina en madrugada eterna.