Product Design

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

Design system as a service: una agencia diseña, gobierna y hace evolucionar el sistema sin handoff final. Seis modelos comparados.

19 de mayo de 20268 min de lectura
drawings of smartphone application screenshots

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.

Foto de Hal Gatewood en Unsplash

Preguntas frecuentes

What is the typical cost of a Design System as a Service engagement in 2026?
It depends on the model. A fixed-scope project lands between USD 15k (starter) and USD 150k+ (enterprise), with mid-market SaaS usually in USD 30k to 70k. Audit and advisory retainers run EUR 2k to 6k per month. An embedded designer or design engineer costs EUR 8k to 18k per month per person. Unlimited-request subscriptions sit at USD 4,800 to USD 12,000 per month per active queue. Full managed DSaaS is priced like a SaaS license, usually a per-seat or per-product fee. Inside each band, the two cost drivers are the breadth of components in scope and how deep the governance work goes.
How long does it take to ship a usable design system through a DSaaS engagement?
A fixed-scope build takes 8 to 16 weeks before consumers can use it in production. A co-build with staged transfer reaches first useful version in 8 to 12 weeks and finishes the transfer phase in another 12 to 16. Embedded designer engagements ship the first usable components in 4 to 8 weeks because they start inside your repo. Subscription queues never produce a usable system in this sense, they produce a stream of components without governance. Building the same system in-house with one designer and one engineer usually takes 6 to 12 months because of the learning curve.
DSaaS vs an in-house design system team: how to decide?
Three questions decide it. First, scale: in-house wins when you have three or more product lines consuming the same system, because the in-house team's overhead amortizes across products. Second, hiring market: building an in-house team costs 12 to 18 months from first hire to a working system, and the senior design-engineer market is thin. Third, opportunity cost: if your product team is fighting for headcount, paying an agency to ship a system in 12 weeks beats waiting two quarters to hire. The hybrid answer (model 4 above) is the right choice for most mid-sized teams: outside expertise during the build, in-house ownership afterwards.
Who owns the IP of the design system at the end of a DSaaS engagement?
In models 1, 3, and 4 (fixed-scope build, embedded designer, co-build with transfer), ownership transfers to the client at the end and the contract should say so explicitly: tokens, Figma source files, code, documentation, and the right to modify and redistribute internally. In model 2 (audit retainer), there is nothing to transfer because the agency only reviewed. In model 5 (subscription), assets the agency produced for you usually transfer per the SLA, but governance does not exist. In model 6 (full managed DSaaS), the agency keeps ownership and the client gets a license; on cancellation the client loses access to future versions but typically keeps a snapshot of the current one. Always have a lawyer read the IP clause before signing.

Studio

Empieza un proyecto.

Un partner único para el producto digital que necesitas construir. Producción más rápida, tecnología moderna, costes reducidos. Un equipo, una factura.