Design system as a service: 6 modelos de agencia comparados en 2026

Design system as a service (DSaaS) es un encargo continuo en el que un equipo externo diseña, gobierna y hace evolucionar tu sistema de diseño como un producto vivo, en lugar de entregar una librería Figma y desaparecer. El modelo existe porque un sistema que se entrega en la semana 12 y no recibe mantenimiento desde la semana 13 se degrada en dos trimestres: los componentes derivan, los tokens se fragmentan y los equipos que deberían usarlo dejan de abrir la documentación.

El mercado de 2026 tiene seis variantes distintas de DSaaS. Comparten el ADN del encargo recurrente, pero cambian en cuánto se queda el cliente al final, cómo se mide la capacidad mensual y de qué saca margen la agencia. Equivocarse de variante cuesta más que equivocarse de agencia.

En 30 segundos

Si tu equipo va a operar el sistema a medio plazo, elige un modelo en el que la propiedad pase (1, 3, 4 abajo). Si no lo va a operar, elige un modelo en el que la agencia se quede al mando (5, 6). Los dos errores típicos: comprar transferencia de propiedad sin tener a quién entregarla (acabas con una librería congelada) y comprar servicio continuo cuando en realidad el presupuesto era para un trabajo finito (pagas para siempre).

Qué medimos

Cada modelo de abajo se valora sobre cinco ejes que deciden si encaja con un comprador concreto.

• Quién es dueño del sistema al final. ¿Tu equipo conserva tokens, componentes, código y Figma al cierre del encargo?
• Forma de la capacidad mensual. ¿La agencia se compromete a una lista finita, a una cola ilimitada o a una franja mensual fija?
• Alcance de la gobernanza. ¿El encargo incluye component owners, reglas de contribución y controles CI, o solo output?
• Forma del coste. Un pago único, retainer mensual, persona embebida o híbrido.
• Coste de salida. Lo que pagas (en dinero o en dolor) para irte.

Los 6 modelos, ordenados por dónde aterriza la propiedad

1. Proyecto de alcance cerrado

El encargo clásico. Compras un sistema definido: tokens, un número fijo de componentes, documentación, librería Figma y código. Ocho a dieciséis semanas, alcance cerrado, precio cerrado. The Design System Guide sitúa este modelo en 15.000 USD para un sistema starter y 150.000+ USD para alcance enterprise, con SaaS mid-market en Serie A o B en torno a 30.000-70.000 USD. Al final, el cliente se queda con todo y la agencia se va.

Encaja con: equipos con un diseñador o un lead front-end que mantendrán el sistema internamente. No encaja con: equipos sin nadie que lo cuide después. Seis meses más tarde los componentes derivan, los overrides en Figma se multiplican y el sistema deja de ser un sistema. Ver los 10 errores que destruyen la coherencia de un sistema.

2. Auditoría y consultoría en retainer

Más ligero. La agencia no construye, revisa. Retainer mensual de 2.000-6.000 € por un asesor senior disponible, más una auditoría trimestral. Sirve cuando un equipo interno ya es dueño del sistema y busca una calibración externa sobre deriva de tokens, cobertura de componentes y cumplimiento de accesibilidad. El entregable es una auditoría escrita, no componentes nuevos. Ver qué es una auditoría de design system para el bucle interno de este trabajo.

Encaja con: equipos internos de dos a cinco personas que quieren una segunda opinión. No encaja con: equipos que aún no tienen un dueño interno. Un asesor no tiene palanca cuando dentro nadie toma decisiones.

3. Diseñador (o design engineer) embebido

La agencia coloca una o dos personas dentro de tu equipo, a tiempo completo o parcial, durante varios trimestres. Trabajan en features y en el sistema en las mismas pull requests. El problema del handoff desaparece porque no hay handoff: la misma persona entrega el componente y la página que lo consume. En 2026 el precio va de 8.000 a 18.000 € al mes por persona embebida, según seniority. Los benchmarks de retainer de diseño en esta franja son de 5.000 a 25.000 USD al mes para SaaS mid-market, con encargos enterprise embebidos por encima de 50.000 USD.

Encaja con: empresas Serie B+ con velocidad de producto pero sin especialista interno del sistema. No encaja con: equipos en fase temprana que pagarían capacidad senior usada al 30%.

4. Co-build con traspaso por fases

La agencia y el equipo interno construyen el sistema juntos durante las primeras 12 a 24 semanas, luego la propiedad pasa por etapas. La agencia se queda como socio de gobernanza dos trimestres más, en retainer reducido. Es el modelo que la literatura sobre gobernanza llama federado: un core team central (al principio la agencia) y squads de producto contribuyentes (el equipo del cliente), con component owners nombrados y un Design Council.

Encaja con: equipos de producto medianos listos para montar un pequeño squad interno de design system, pero no desde el día uno. No encaja con: equipos que no quieren tocar el sistema nunca. La fase de traspaso funciona solo si los diseñadores internos cogen las riendas de verdad.

5. Suscripción de solicitudes ilimitadas

Cuota mensual, plaza fija, solicitudes ilimitadas, una o dos tareas activas a la vez. Es la ola 2026 de las suscripciones de diseño (Superside, Wavespace, Awesomic y similares). Precios: 4.800-12.000 USD al mes por cola activa. La agencia se hace cargo del SLA, pero los activos viven en tu Figma. Sin gobernanza, sin reglas de contribución, sin auditoría. Solo throughput en la cola de solicitudes.

Encaja con: startups con picos de demanda de diseño y cero tiempo para gestionar proveedores. No encaja con: empresas que quieren un sistema coherente. La cola de suscripción produce output de diseño, no un sistema gobernado. A doce meses el trabajo deriva porque nadie del lado agencia cobra por imponer coherencia.

6. DSaaS gestionado completo

La agencia es dueña del sistema como producto. El cliente lo consume vía licencia o cuota por asiento, igual que consumiría una librería UI de terceros. Ejemplo en el mercado: la oferta DSaaS de Meiuca. La agencia lleva la roadmap, el modelo de contribución, los tokens, los componentes y la documentación. El cliente paga una cuota recurrente y recibe releases versionadas.

Encaja con: equipos que explícitamente no quieren el design system como capacidad interna. No encaja con: empresas cuyo producto se diferencia por la interfaz. Alquilar el sistema de otro implica heredar su roadmap y dejar de diferenciarse en la artesanía. La compensación es parecida a usar una librería de terceros, que ya hemos calificado de atajo caro en la mayoría de casos.

Cómo elegir entre los seis

Procede en orden.

1. ¿Habrá alguien dentro que opere el sistema dentro de doce meses? Si no, los modelos 1, 3, 4 no son para ti. Heredarías un sistema congelado. Mira 2, 5 o 6.
2. ¿Necesitas un sistema u output de diseño? La suscripción 5 produce output. Los modelos 1, 3, 4, 6 producen sistema gobernado. Confundir las dos cosas es el desajuste más común.
3. ¿La UI es un foso competitivo para tu producto? Si sí, el modelo 6 (sistema alquilado) no encaja. Elige 1, 3 o 4.
4. Forma del presupuesto: capital u operativo? Los modelos 1 y partes del 4 son tipo capital. Los modelos 2, 3, 5, 6 son operativos. Finanzas se preocupa por esto aunque producto lo olvide.
5. Carga de cumplimiento. Sector público, fintech y sanidad suelen necesitar la lista de contribuyentes, las trazas de auditoría y la evidencia de accesibilidad recogidas durante la construcción. El modelo 5 casi nunca lo entrega. Los modelos 1, 3, 4 sí, si lo escribes en el alcance.

Qué debe haber siempre, sea cual sea el modelo

Tres cosas separan un encargo DSaaS serio de un archivo de Figma disfrazado de uno.

• Una capa de tokens, no solo componentes. Tokens de color, espaciado, tipografía, radios y sombras son los cimientos. Componentes sin tokens son CSS vestido. Hemos escrito sobre cómo gobernamos los tokens en varios proyectos.
• Un protocolo de gobernanza por escrito. Quién propone un componente, quién aprueba, quién lo deprecia, quién es dueño de cada pieza. La guía de Figma trata el modelo de contribución como una cuestión de primer nivel. Tu contrato también debería.
• Código, no solo Figma. Un sistema que vive solo en Figma son dos sistemas: el de diseño y el de producción. La deriva entre ambos es el trabajo que nadie quiere hacer. La agencia contratada debe entregar los dos.

Cuándo DSaaS es la respuesta equivocada

Tres casos honestos.

• Pre product-market-fit. Antes de que un SaaS sepa qué vende, un design system es sobrecarga. Usa una librería de terceros, lanza la v1 y revísalo en Serie A.
• Un producto, un equipo, sin plan de escala. Cuatro personas haciendo una app para un segmento no necesitan gobernanza. Una carpeta de componentes a nivel página dentro de la app es suficiente.
• Ya tienes un sistema que funciona. Un sistema que va y del que nadie se queja no necesita un socio DSaaS. Necesita la auditoría trimestral (modelo 2) y nada más.