Por qué “build vs buy” simplifica mal el problema
En sportsbooks, build vs buy suele plantearse como una decisión de producto (tiempo de salida, coste inicial, features). En realidad es una decisión de arquitectura de control: quién define el ritmo de cambio, el margen operativo y la capacidad de absorber shocks (regulación, picos de demanda, cambios en feeds, fraudes, latencia).
La pregunta útil no es “¿lo construyo o lo compro?”, sino:
- ¿Qué debo controlar para proteger margen y continuidad operativa?
- ¿Dónde puedo aceptar dependencia sin perder capacidad de negociación?
- ¿Qué decisiones de hoy fijan mis costes unitarios y mi velocidad de iteración dentro de 12–24 meses?
El framing correcto es control vs dependencia y leverage de infraestructura a largo plazo.
Control vs dependencia: el verdadero trade-off
Control no es “tener código”; es gobernar invariantes
El control relevante en un sportsbook está en los puntos donde una dependencia externa puede:
- introducir incertidumbre (SLA difuso, cambios no versionados, incidentes recurrentes),
- forzar costes variables (pricing por volumen que erosiona margen en crecimiento),
- limitar diferenciación (mismo core que competidores, misma latencia, misma flexibilidad),
- bloquear compliance (trazabilidad, auditoría, segregación por jurisdicción).
Control significa poder definir y auditar invariantes como: latencia máxima por flujo crítico, idempotencia en settlement, consistencia de exposure, determinismo en grading, y observabilidad completa end-to-end.
Dependencia aceptable vs dependencia estructural
La dependencia es aceptable cuando:
- es conmutativa (puedes reemplazar proveedor sin reescribir el core),
- es acotada (impacta un dominio periférico, no el P&L diario),
- está contratada y medible (SLA, penalizaciones, límites de cambios),
- tiene abstracción (interfaz interna, adaptadores, pruebas de contrato).
La dependencia se vuelve estructural cuando afecta el “nervio central”: pricing, risk, wallet/ledger, settlement, o la capa de orquestación de eventos. Sobre el riesgo sistémico de este patrón, ver /es/insights/estrategia/dependencia-de-proveedores-como-riesgo-estructural-en-infraestructura-de-sportsbooks.
Infrastructure-first: dónde se crea el leverage real
El leverage está en la plataforma, no en la feature
En un sportsbook, las “features” tienden a ser imitables. La ventaja sostenible suele venir de capacidades infra que reducen coste unitario y aumentan velocidad:
- event-driven backbone con semántica clara (at-least-once + idempotencia, o exactly-once donde aplique),
- modelo de datos de riesgo y exposición coherente y auditable,
- observabilidad operable (tracing, métricas por mercado/fixture, SLOs por flujo),
- control de latencia (prioridades, backpressure, degradación controlada),
- testing de producción (shadow traffic, replay de eventos, canaries).
Cuando estas bases están en un vendor y no en tu plataforma, tu roadmap se convierte en “solicitudes” y tu ciclo de aprendizaje se ralentiza.
La escalabilidad no es un claim; es un diseño de fallos
Muchas decisiones build/buy se justifican con “escala”. La escala relevante en sportsbooks es picos + criticidad: pre-match vs in-play, ventanas de goles, cashout, suspensión/reapertura de mercados, y reconciliación post-evento. Si la arquitectura no modela fallos (feeds inconsistentes, retrasos, duplicados, cortes parciales), la “escalabilidad” es estética.
Un análisis más profundo de los mitos de escalabilidad típicos en este dominio: /es/insights/ingenieria/la-ilusion-de-escalabilidad-en-arquitecturas-de-sportsbooks.
Un marco de decisión: qué controlar, qué modularizar, qué comprar
1) Identifica “control planes” vs “data planes”
Separar:
- Control plane: reglas, políticas, configuración, límites de riesgo, suspensión, KYC/AML gating, enrutamiento por jurisdicción.
- Data plane: flujos de eventos, pricing ticks, bet placement, cashout quotes, settlements, ledger postings.
En sportsbooks, el control plane suele requerir gobernanza interna; el data plane puede tolerar más compra si está instrumentado y es reemplazable.
2) Clasifica dominios por impacto en margen y continuidad
Una heurística práctica:
- Tier A (core, controlar): ledger/wallet contable, risk & exposure, bet lifecycle, settlement/grading, limit management, observabilidad/SRE.
- Tier B (diferenciación táctica): pricing interno en segmentos donde compites (por deporte/mercado), tooling de traders, promo engine con guardrails.
- Tier C (commodity, comprar): CMS, BI genérico, CRM, antifraude complementario, parte de identidad (con buen diseño de integración).
Lo crítico: incluso en Tier C, diseña exit desde el día 1 (contract tests, abstracción, portabilidad de datos).
3) Modela el coste total como función de dependencia
El TCO real no es licencia vs salarios. Incluye:
- coste de cambio (switching cost): reescritura + migración de datos + re-certificación regulatoria,
- coste por latencia: pérdida de conversión en in-play, errores de cashout, suspensión tardía,
- coste de incidentes: burn de equipos + pérdida de confianza + exposición regulatoria,
- coste de roadmap: features bloqueadas por API constraints o ventanas del proveedor,
- coste de margen: tarifas variables que crecen con el éxito.
Si no puedes cuantificar al menos rangos de estos costes, el “buy” puede parecer barato por definición.
Patrones de arquitectura para reducir dependencia sin “rebuild completo”
Adaptadores + contratos + replay: el triángulo de independencia
- Adaptador interno por proveedor (interface estable).
- Contract tests que validen cambios y degradación.
- Event log/replay para reproducir incidentes y migrar.
Esto permite comprar hoy sin hipotecar mañana.
“Strangler” por flujos, no por módulos
Migrar por flujos end-to-end (ej. bet placement → acceptance → ledger posting) en lugar de “módulos” aislados. La ventaja: puedes medir SLOs, comparar rendimiento, y revertir con seguridad.
Data ownership: tuyo aunque el procesamiento sea externo
Aunque uses servicios externos para partes del procesamiento, mantén:
- tu event store o al menos una copia íntegra y versionada,
- tu modelo de identidad de apuestas (IDs, correlación, auditoría),
- tu ledger como fuente de verdad contable.
Sin ownership de datos, no hay salida ordenada.
Señales de alerta: cuándo el “buy” ya te está costando estrategia
Indicadores técnicos
- No puedes instrumentar latencia/errores por mercado o fixture.
- No puedes simular/reproducir incidentes por falta de event history.
- Integraciones punto a punto sin esquema versionado.
- Cambios del proveedor rompen comportamiento sin semver ni avisos operables.
- Observabilidad limitada a dashboards del vendor.
Indicadores de negocio
- Margen cae con crecimiento por pricing por volumen.
- Roadmap dictado por “capabilities” del proveedor.
- Diferenciación imposible en in-play/cashout/limits.
- Multi-jurisdicción se vuelve un proyecto continuo por constraints del stack externo.
Cuando aparecen 2–3 de estos, la discusión debe pasar de build vs buy a re-architecture para recuperar control.
Key takeaways
- La decisión estratégica es control vs dependencia, no build vs buy.
- El leverage sostenible se crea en plataforma: eventos, ledger, risk, observabilidad y latencia.
- Compra lo commodity, pero diseña portabilidad y salida desde el primer día (adaptadores, contratos, replay).
- Si el proveedor limita SLOs, datos o roadmap, ya no es un “buy”: es un riesgo estructural.
Próximo paso: alinear estrategia y arquitectura
Si el objetivo es competir en margen, velocidad y resiliencia, el plan debe partir de un mapa claro de dominios Tier A/B/C y de una arquitectura que minimice switching cost. Para contexto adicional y piezas relacionadas, revisar /es/insights y los análisis enlazados en las secciones anteriores.