Build vs. Buy: ¿desarrollar la integración de hardware o utilizar una API?

La decisión que nadie explica bien

Cuando un cliente te pide que tu SaaS lea sus terminales biométricos, hay dos caminos para responderle. Build: tu equipo estudia el protocolo del fabricante, escribe el adaptador, monta la infraestructura y mantiene todo vivo. Buy: consumes una API gestionada como API Connect que ya resolvió ese problema y expone los equipos como endpoints REST.

La conversación suele empezar mal porque se compara lo equivocado: se compara el precio del desarrollo contra el precio de la suscripción. La comparación correcta es el costo total de propiedad del primer año contra una línea en tu plan de gastos. Veamos por qué.

Qué implica realmente el Build

Desarrollar la integración propia no es un sprint de dos semanas. Es un módulo permanente de tu producto con estos componentes:

• Ingeniería del protocolo: los terminales no hablan HTTP. Implementar el modo push/ADMS significa manejar sesiones, formatos binarios de transferencia de datos y variaciones por familia de firmware. Cada modelo nuevo es un dialecto nuevo.
• Infraestructura pública: para que los equipos se conecten a tu SaaS, necesitas un servidor con dirección pública estable, TLS, alta disponibilidad y monitorización 24/7. No es la misma infraestructura que la API de tu negocio: es infraestructura de dispositivo.
• Almacenamiento de eventos: cada marcación llega por su cuenta; necesitas ingesta tolerante a picos, deduplicación (los terminales reenvían al reconectar) y consultas eficientes por rango de fechas.
• Mantenimiento permanente: firmware actualiza comportamientos, fabricantes corrigen bugs, clientes reportan modelos raros. El adaptador no se "termina": se mantiene de por vida.
• Seguridad: autenticar dispositivos que no tienen usuario y contraseña, con todo lo que eso implica en riesgo y auditoría.

Qué implica realmente el Buy

Con una API gestionada, el trabajo del adaptador, la infraestructura de conexión y el mantenimiento del protocolo ya están hechos y se mantienen solos. Tu parte del trabajo es la que sí agrega valor a tu SaaS:

• Autenticación: un login estándar contra la API te da un token JWT con expiración.
• Consumo: reportes por terminal con rango de fechas y paginación, y eventos en tiempo real (por webhook o stream) para la lógica urgente.
• Gestión: altas de usuarios y credenciales por número de serie vía API.

curl -X POST https://TU-DOMINIO-API/auth/login \
  -H "Content-Type: application/json" \
  -d '{"username": "tu_usuario", "password": "tu_password"}'

# Token listo para llamar a la API
{
  "access_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9...",
  "token_type": "bearer",
  "expires_in": 3600
}

La comparación honesta

Cuándo SÍ tiene sentido el Build

Para no ser engañosos: existen casos donde construir es la decisión correcta. Todos comparten estas características:

• Tienes un requisito muy específico que ninguna API expone (por ejemplo, control directo de un periférico no soportado).
• Tienes un equipo de ingeniería dedicado que puede asumir el mantenimiento indefinido sin sacrificar el roadmap.
• Tu roadmap de producto incluye hardware propio: el adaptador sería un activo estratégico, no un parche.
• El volumen justifica la inversión: miles de terminales donde cada centavo por terminal cambia la economía.

Si tu caso es "mi SaaS necesita leer terminales ZKTeco de mis clientes", ninguno de esos cuatro aplica. Estás en el territorio del Buy.

La regla de decisión en una frase

Construye lo que diferencia tu producto; compra todo lo que no. Tu SaaS no compite por saber parsear el protocolo ADMS — compite por nómina mejor, condominios mejor, seguridad mejor. La integración de hardware es un medio, no tu producto.

Preguntas frecuentes