Usamos IA para escribir más rápido, no para decidir qué es verdad. Alguien de Digital Samba ha leído cada línea de este artículo antes que tú.
¿Cuánto cuesta desarrollar una aplicación de vídeo con WebRTC? No hay una cifra única. Las estimaciones que verás citadas van desde unos 15.000 € para un proyecto pequeño hasta más de 150.000 € para una plataforma a escala, con tarifas de desarrollo de entre 30 € y 120 € la hora según la región del equipo. Ese rango es tan amplio por un motivo: el precio depende de la escala, la geografía y el alcance de funciones, y casi todo el coste real aparece después del prototipo.
La decisión de construir o comprar vídeo en tiempo real casi siempre empieza como una cuestión de coste. Un programador levanta una llamada uno a uno (P2P) en una tarde, la demo se ve pulida y, de repente, la estimación de ingeniería dice «unas cuantas semanas». Esa estimación no está mal; es que responde a la pregunta equivocada. Pone precio al prototipo, no al sistema de producción en el que ese prototipo tiene que convertirse, y eso es otra pregunta muy distinta. Para cuando la distancia entre los dos se hace visible, el equipo ya se ha comprometido con un camino que consume en silencio de 6 a 18 meses de capacidad de ingeniería y deja un rastro de obligaciones operativas que nunca se cierran del todo.
Este artículo es un mapa de componentes de coste para cualquiera que se plantee en serio si construir vídeo WebRTC desde cero. Una cifra suelta no diría nada, porque depende demasiado de la escala, la geografía y el alcance de funciones. En su lugar, descompone el problema en sus partes reales: esfuerzo de ingeniería, carga de infraestructura y los costes ocultos que solo aparecen cuando ya tienes usuarios de verdad. También propone un marco sencillo para tomar la decisión de construir o integrar en el eje correcto.
Índice de contenidos
WebRTC es un estándar nativo del navegador. Chrome, Firefox, Safari y Edge traen las API integradas. Establecer una videollamada directa entre dos navegadores no requiere infraestructura de medios propia, porque los navegadores negocian la conexión, cifran los flujos con DTLS-SRTP (el protocolo de cifrado que WebRTC usa por defecto) y pasan los medios de igual a igual. Un programador que ya entienda la API puede tener algo visualmente convincente funcionando en uno o dos días.
Esto es a la vez la mayor virtud de WebRTC y el origen de casi todas las subestimaciones de lo que cuesta construir vídeo de verdad. El prototipo es barato. El problema es que resuelve una topología muy concreta: dos participantes en redes razonablemente abiertas y con navegadores actualizados. Quita cualquiera de esas condiciones (añade un tercer participante, pon a un usuario detrás del cortafuegos de una empresa, prueba en Safari de iOS o intenta grabar la sesión) y el prototipo empieza a caerse. Cada uno de esos cambios te obliga a añadir infraestructura o ingeniería que el prototipo nunca necesitó.
La distancia entre «una llamada que funciona en una demo» y «una llamada que funciona de forma fiable para 1.000 usuarios en distintos dispositivos y redes» es donde vive el coste real.
WebRTC se ocupa de los medios, pero no del paso de coordinación previo: decirles a dos clientes cómo encontrarse, intercambiar las descripciones de sesión (SDP) y transmitir los candidatos ICE. Esa es la capa de señalización, y tienes que construirla y operarla tú.
Un servidor de señalización no es especialmente difícil en su primera versión: un servidor WebSocket que retransmite mensajes entre pares. Pero hay que alojarlo, protegerlo con TLS, monitorizarlo y escalarlo. Con carga, necesita escalado horizontal con sesiones persistentes (sticky sessions) o un almacén de sesiones compartido. Cuando añades salas, autenticación y eventos de webhook, se convierte en un servicio importante por derecho propio. El esfuerzo de ingeniería aquí va de días en el caso más simple a semanas cuando cuentas el endurecimiento y las herramientas operativas.
Cuando dos navegadores intentan conectarse de igual a igual, usan ICE, un proceso que prueba varias rutas candidatas por orden de preferencia. Un servidor STUN ayuda a cada cliente a descubrir su dirección IP pública, lo que suele bastar para usuarios en redes domésticas. Pero una parte importante de los usuarios reales está detrás de NAT simétricas, cortafuegos corporativos o VPN donde el igual a igual directo queda bloqueado. Para esos usuarios, el tráfico tiene que pasar por un servidor TURN.
El relevo TURN consume mucho ancho de banda. Cada paquete de vídeo y audio pasa por tu infraestructura TURN, lo que significa que los costes de salida (egress) escalan directamente con el uso. Estimar el consumo de TURN antes de tener tráfico de producción es difícil, porque las tasas de uso de TURN varían mucho según el perfil de tus usuarios, pero no es un coste que puedas ignorar en el cálculo del coste total de propiedad (TCO). Operar TURN a escala también exige distribución geográfica: un servidor TURN en el continente equivocado añade cientos de milisegundos de latencia y degrada la calidad de la llamada de forma notable.
El igual a igual solo funciona bien con muy pocos participantes. A partir de dos o tres, la topología en malla (donde cada participante envía un flujo a todos los demás) se vuelve impracticable. Cada participante sube una copia de su propio flujo a cada uno de los demás, así que la subida por cliente crece de forma lineal con el número de participantes, mientras que el total de flujos en la malla crece con el cuadrado de ese número. La solución estándar es una Unidad de Reenvío Selectivo (SFU): un servidor de medios que recibe los flujos de cada participante y reenvía los flujos adecuados a cada receptor, sin decodificar ni recodificar.
Construir y operar un SFU es, con diferencia, el mayor factor de coste al escalar WebRTC. Existen opciones de código abierto, como Janus, Mediasoup y Pion, pero código abierto significa que el código es gratis, no que el esfuerzo de implementación lo sea. Desplegar un SFU correctamente, ajustarlo para Simulcast (donde los emisores transmiten varias capas de resolución a la vez para que el SFU se adapte a las condiciones de cada receptor) y escalarlo horizontalmente con carga variable suman un proyecto serio de ingeniería de infraestructura. Los equipos lo subestiman de forma rutinaria como cuestión de semanas cuando de hecho es cuestión de meses, sobre todo una vez que lo juntas con observabilidad, conmutación por error y distribución geográfica.
La grabación en el servidor, es decir, capturar una vista compuesta de una llamada de varios participantes, obliga al SFU o a un nodo de grabación aparte a mezclar los flujos de audio y vídeo y escribirlos en un archivo. Esto es caro en cómputo: componer vídeo en tiempo real, aun sin recodificar, consume recursos de CPU importantes. Los archivos grabados luego hay que almacenarlos, normalmente en almacenamiento de objetos, y al final servirlos a los usuarios o exportarlos, y las dos cosas conllevan costes de salida. Para productos donde la grabación es una función central y no un caso puntual, los costes de infraestructura aquí merecen su propia partida.
El comportamiento de WebRTC varía entre navegadores de formas que no siempre están documentadas y que cambian con cada versión del navegador. Safari ha ido históricamente por detrás en soporte de funciones WebRTC y sigue divergiendo de Chrome en ciertos comportamientos de códecs y API. El Safari móvil de iOS impone restricciones adicionales (por ejemplo, el comportamiento de getUserMedia, los límites al compartir pantalla y la gestión de pestañas en segundo plano) que exigen rutas de prueba propias. Firefox tiene códecs por defecto distintos. Los WebView antiguos de Android en dispositivos de gama media presentan sus propios modos de fallo.
El resultado es que el QA multinavegador y de dispositivos no es una inversión puntual. Es continua. Cada vez que Chrome lanza una versión nueva conviene hacer pruebas de regresión, y ese ritmo se acelera: Chrome pasa de un ciclo de versión mayor de cuatro semanas a uno de dos semanas el 8 de septiembre de 2026, lo que casi duplica los puntos de control de versión que tienes que seguir. Es tiempo de ingeniería que no va a construir funciones nuevas. A lo largo de doce meses, esto suma una cantidad de horas considerable.
WebRTC cifra los medios con DTLS-SRTP por defecto, lo que cubre la seguridad del transporte. Pero los sistemas de producción necesitan más que la base. La gestión de claves para establecer la sesión hay que manejarla bien. Si tu caso de uso implica contenido sensible, como consultas sanitarias, conversaciones jurídicas o asesoramiento financiero, quizá tengas que valorar el cifrado de extremo a extremo (E2EE), que descarta ciertas capacidades del lado del servidor como la grabación y exige un diseño de protocolo cuidadoso. La señalización hay que protegerla aparte. Los tokens de autenticación hay que acotarlos y validarlos. Nada de esto es prohibitivamente difícil, pero cada elemento representa tiempo de ingeniería y una responsabilidad continua.
Si das servicio a usuarios de la UE o tratas datos de residentes en la UE, se aplica el RGPD. Eso significa acuerdos de tratamiento de datos con cada subencargado (tu proveedor de nube, tu CDN, tu herramienta de monitorización, tu proveedor de infraestructura TURN), decisiones sobre residencia de datos y la capacidad de atender solicitudes de supresión y portabilidad. Los productos de telesalud en EE. UU. tienen que lidiar con la HIPAA. Los productos de EdTech que atienden a menores de 13 años en EE. UU. se topan con la COPPA. El trabajo de cumplimiento suele ser invisible en las estimaciones de ingeniería iniciales y muy visible en las facturas legales y en los lanzamientos que se retrasan.
No puedes operar un sistema de vídeo en producción sin observabilidad. Necesitas métricas de calidad de llamada, como pérdida de paquetes, jitter, tiempo de ida y vuelta y bitrate, presentadas de forma que te dejen diagnosticar los problemas que reportan los usuarios. Necesitas alertas cuando los nodos SFU dejan de estar sanos. Necesitas cobertura de guardia, porque las videollamadas fallan a horas inoportunas. Construir desde cero una capa de monitorización de la calidad de experiencia (QoE) es un proyecto de ingeniería de varias semanas, y la carga de guardia que genera es continua.
El coste que la mayoría de las estimaciones de construcción se saltan por completo es el mantenimiento. La especificación de WebRTC sigue evolucionando, las implementaciones de los navegadores cambian y el IETF sigue refinando los estándares relacionados. Aparecen parches de seguridad y tu biblioteca de SFU publica de vez en cuando sus propios cambios que rompen la compatibilidad. Cada uno de estos exige atención de ingeniería: a veces unas horas, a veces unos días y, en ocasiones, una crisis que necesita respuesta urgente. En un horizonte de dos a tres años, el mantenimiento consume con facilidad el equivalente a otro ciclo de implementación completo.
Más allá de los componentes directos de infraestructura e ingeniería de arriba, hay cuatro costes ocultos que sorprenden una y otra vez a los equipos que deciden construir.
El eje correcto para esta decisión no es «construir» frente a «comprar un producto SaaS». Es construir frente a integrar vídeo: operar todo el stack tú mismo frente a integrar un servicio programable que se encarga de la infraestructura y a la vez expone las interfaces que necesitas para personalizar el producto.
Construir el stack tú mismo es la opción racional cuando la comunicación en tiempo real es propiedad intelectual central, es decir, cuando la propia canalización de medios es el producto, cuando necesitas capacidades que ningún servicio existente expone o cuando tu escala y el tamaño de tu equipo hacen que operar infraestructura salga realmente a cuenta frente a las tarifas del servicio. También tiene sentido cuando cuentas con experiencia en tiempo real dentro de casa y la carga de mantenimiento continuo ya está contemplada en la plantilla.
Integrar gana en el caso mucho más habitual: cuando el vídeo es una función de tu producto y no el producto en sí, cuando el tiempo hasta el lanzamiento importa, cuando la experiencia de tu equipo está en tu dominio y no en la infraestructura de medios, y cuando prefieres ver los costes por adelantado antes que descubrirlos a posteriori. Una matización sobre el coste «predecible»: las tarifas por uso del lado de la integración siguen escalando con el crecimiento, igual que los costes de infraestructura cuando construyes tú. La ventaja real de integrar no es que la factura sea fija. Es que el coste es visible por adelantado y la carga operativa recae en el proveedor, no en tu equipo.
Un marco de TCO útil: estima las semanas de ingeniería necesarias para llegar a calidad de producción (señalización, TURN, SFU, grabación, QA, seguridad, cumplimiento y observabilidad) y exprésalas como porcentaje de todo tu plan de ingeniería para los próximos 12 meses. Para la mayoría de los equipos de producto, ese número es incómodamente alto. La escala a la que el autoalojamiento empieza a compensar tiende a llegar antes de lo que crees, con un nivel de uso moderado en lugar de solo al tamaño de las plataformas más grandes, aunque aún hace falta un volumen real antes de que la economía se incline a favor de construir.
Los componentes de coste que hemos mapeado arriba encajan de cerca con lo que un SDK de integración bien diseñado te quita de encima.
El escalado del SFU, el relevo TURN y la distribución geográfica de la infraestructura de medios pasan a ser problema del proveedor. El QA multinavegador y de dispositivos, ese trabajo de regresión continuo que exige cada versión del navegador, queda absorbido por el servicio. Incluso el trabajo de base del cumplimiento, la residencia de datos en la UE y la gestión de subencargados, se traslada en gran parte a la capa de infraestructura, aunque tú sigues siendo el responsable del tratamiento de los datos personales de tus llamadas.
Esa división del trabajo es lo que hemos construido en torno a Digital Samba. La infraestructura está alojada en Europa y nuestro acuerdo de tratamiento de datos (DPA) es deliberadamente sencillo: para la mayoría de los equipos se puede firmar tal cual para cubrir la residencia de datos y la gestión de subencargados, de modo que cumplir requisitos estrictos de soberanía del dato, privacidad y seguridad no se convierta en una negociación eterna del DPA.
En el lado de la ingeniería, el SDK de integración de Digital Samba se distribuye bajo la licencia BSD-2-Clause, así que puedes inspeccionar y extender el código del SDK con libertad, y sigue siendo totalmente programable en vez de encerrarte en una interfaz fija. La capa de SFU está construida sobre Janus, un servidor de medios de código abierto asentado y bien documentado, y el cifrado de extremo a extremo está disponible como opción para los casos en los que ningún servidor, incluido el nuestro, puede leer los medios.
En la práctica, los componentes que generan mayor carga continua en un stack autoalojado (operación del SFU, salida de TURN, compatibilidad con navegadores, infraestructura de cumplimiento y mantenimiento perpetuo) se gestionan por ti, y tú mantienes el control total sobre las integraciones y personalizaciones que tu producto necesita.
Integrar tampoco está libre de compromisos, y es justo sopesarlos junto a los costes ocultos de construir descritos arriba. Asumes una dependencia de los planes de producto y las decisiones de precio del proveedor. La mayoría de los contratos implican un periodo de compromiso en vez de pura flexibilidad de pago por uso. Y si algún día necesitas cambiar de proveedor, migrar un producto en marcha a un nuevo stack de vídeo tiene un coste propio nada trivial.
No hay una cifra única para cuánto cuesta construir una app WebRTC, pero los componentes que marcan el coste real están bien definidos, y ninguno es opcional cuando construyes para producción. El prototipo es barato. Las capas de señalización, TURN, SFU, grabación, QA, seguridad, cumplimiento, observabilidad y mantenimiento no lo son, y no dejan de costar una vez construidas.
La forma correcta de plantear la decisión no es la estimación del prototipo. Es el coste total de propiedad completo: mantenimiento continuo, coste de oportunidad del equipo y todo lo demás que hemos cubierto. Para la mayoría de los equipos de producto, ese análisis apunta con claridad hacia la vía de la integración, sobre todo cuando la opción de integrar está alojada en Europa y construida sobre una base de código abierto asentada, con los compromisos nombrados con honestidad en vez de disimulados.
Si quieres mirar la opción de integrar en términos concretos, la página de precios de Digital Samba es un buen punto de partida. Y si todavía estás resolviendo la decisión de construir o integrar en detalle, nuestra guía de construir vs integrar cubre los compromisos con más profundidad.
El coste de construir no es la demo. Es todo lo que viene después.
No hay una cifra única, porque el coste depende de la escala que necesites soportar, las funciones que requieras, la experiencia previa del equipo y la distribución geográfica de tu infraestructura. Las estimaciones de mercado suelen ir de unos 15.000 € para un proyecto pequeño a más de 150.000 € para una plataforma a escala, con tarifas de entre 30 € y 120 € la hora según la región. Un prototipo se puede construir en días con un coste de infraestructura casi nulo. Un sistema de producción, con SFU, relevo TURN, grabación, QA multinavegador, observabilidad y cumplimiento, suele requerir de tres a nueve meses de ingeniería especializada más gasto operativo continuo. La pregunta más útil es: ¿qué porcentaje de tu plan de ingeniería estás dispuesto a dedicar a la infraestructura de medios durante los próximos dos años?
Un prototipo suele demostrar una llamada de dos participantes en una red favorable usando las API de WebRTC integradas en el navegador. Para ese caso no hace falta infraestructura de medios. La producción añade soporte para varios participantes (que requiere un SFU), conectividad fiable para usuarios en redes restringidas (que requiere TURN), compatibilidad multinavegador (que requiere QA continuo), grabación, endurecimiento de seguridad, cumplimiento y observabilidad. Cada una de esas cosas añade esfuerzo de ingeniería y coste de infraestructura que el prototipo nunca tocó.
El mantenimiento continuo incluye las pruebas de regresión de compatibilidad con navegadores (Chrome pasa a un ciclo de versión mayor de dos semanas el 8 de septiembre de 2026, frente a las cuatro anteriores), las actualizaciones del SFU y sus dependencias, los parches de seguridad, la monitorización y la cobertura de guardia, y la rearquitectura periódica según cambia tu escala. Los equipos que construyen su propio stack informan una y otra vez de que el mantenimiento consume una fracción apreciable del esfuerzo de construcción original cada año, a menudo entre el 20 y el 40 por ciento anual repartido en el tiempo.
Sí, en la mayoría de los casos de producción necesitas los dos. TURN hace falta para usuarios en redes restringidas, normalmente entre el 15 y el 40 por ciento del tráfico real según el perfil de tus usuarios, y su coste escala con el ancho de banda de salida, que a su vez depende del uso. Un SFU hace falta para llamadas de más de dos o tres participantes. Los costes del SFU incluyen cómputo, salida y la carga de ingeniería de operar el servicio. Los dos necesitan distribución geográfica para una latencia aceptable, lo que multiplica los costes de infraestructura. Las cifras exactas dependen de tus patrones de tráfico. La página de precios de Digital Samba da una idea de cómo se ve la alternativa de integrar en comparación.
Se reduce a lo que el vídeo en tiempo real significa para tu negocio. Si es genuinamente central para tu producto, si necesitas capacidades que ningún servicio ofrece o si ya cuentas con experiencia en tiempo real dentro de casa y el equipo para mantenerla a largo plazo, construir puede tener sentido. Para la mayoría de los equipos, en cambio, el vídeo da soporte a otro producto en vez de ser el producto en sí, y el tiempo hasta el lanzamiento y unos costes visibles y predecibles importan más que poseer cada capa del stack. En ese caso, integrar suele ganar.
Con un SDK de integración bien diseñado, eliminas o reduces mucho: la construcción y operación del SFU, la infraestructura y salida de TURN, el QA multinavegador y de dispositivos, la infraestructura de cumplimiento (residencia de datos del RGPD, gestión de subencargados), el mantenimiento de WebRTC a medida que evolucionan la especificación y los navegadores, y la construcción de observabilidad. Mantienes el control total sobre la experiencia de producto y la lógica de la aplicación: estás integrando infraestructura, no renunciando a la programabilidad.