Estudio pequeño o gran agencia para tu SaaS: cuándo gana cada uno

Elegir entre un estudio pequeño y una gran agencia para un SaaS es una decisión sobre el alcance del trabajo antes que sobre el proveedor. La resuelven tres respuestas: cuántas líneas de trabajo tienen que avanzar a la vez, cuántas personas tienen que aprobar cada decisión y qué le pedirá demostrar tu departamento de compras al proveedor antes de firmar. El tamaño del proveedor viene después.

Aquí, estudio pequeño significa un equipo de 2 a 15 personas en el que quien define el trabajo es quien lo diseña y lo desarrolla. Gran agencia significa una estructura de 50 personas o más, con departamentos separados de ventas, cuentas, gestión de proyectos y entrega. Las empresas medianas quedan en medio y toman rasgos de ambas. Si todavía dudas entre un estudio y un profesional por libre, empieza por agencia o freelance para un MVP.

La respuesta corta

Elige un estudio pequeño cuando haya un solo producto que diseñar y desarrollar con un solo equipo, y quieras hablar cada semana con quien hace el trabajo. Elige una gran agencia cuando el trabajo tenga que avanzar en cuatro o más líneas en paralelo antes de una fecha fija, cuando el departamento de compras de tus clientes pida informes de seguridad y coberturas de seguro que el proveedor ya debe tener, o cuando necesites cobertura a cualquier hora.

La primera versión de un producto web encaja en el primer caso. Un lanzamiento en web, iOS y Android para una gran empresa, atado a una fecha que el consejo ya ha anunciado, encaja en el segundo.

Cara a cara: ocho cosas que cambian con el tamaño

• Con quién hablas cada semana. Estudio pequeño: el diseñador y el desarrollador que hacen el producto. Gran agencia: un account o project manager que traslada todo al equipo.
• Capacidad en paralelo. Estudio pequeño: una o dos líneas a la vez. Gran agencia: muchas líneas, con gente asignada a todas a la vez.
• Aprobaciones dentro del proveedor. Estudio pequeño: una o dos personas. Gran agencia: varios niveles, como delivery lead, responsable de QA y director de cuenta.
• Pruebas para compras. Estudio pequeño: depende mucho, y muchos no tienen ni informe SOC 2 ni certificado ISO/IEC 27001. Gran agencia: a menudo tiene los dos, porque los clientes enterprise los piden.
• Dependencia de personas clave. Estudio pequeño: alta, porque si se va una persona se va buena parte del conocimiento. Gran agencia: más baja, porque otros cubren los puestos.
• Qué pagas en la factura. Estudio pequeño: sobre todo horas de diseño y desarrollo. Gran agencia: cuentas, PMO y QA aparecen como partidas propias.
• Arranque. Estudio pequeño: puede empezar en pocas semanas, y el techo es la capacidad. Gran agencia: tarda más en arrancar, pero en marcha suma diez personas rápido.
• Alcance más allá del producto. Estudio pequeño: diseño de producto y desarrollo, a veces marca. Gran agencia: suma campañas, compra de medios, paneles de investigación y localización a muchos mercados.

¿El tamaño del equipo cambia las probabilidades de éxito?

El tamaño del proyecto, sí, y los datos son antiguos y coherentes. Fred Brooks mostró en The Mythical Man-Month (1975) que las líneas de comunicación de un equipo crecen como n(n-1)/2. Cinco personas tienen 10 líneas. Diez tienen 45. Treinta tienen 435. Cada línea es un sitio donde una decisión se puede malinterpretar o perder entre dos reuniones. Amazon organizó sus equipos con la misma cuenta: AWS describe sus equipos de dos pizzas como grupos tan pequeños que dos pizzas bastan para alimentarlos, y los mantiene así para recortar líneas de comunicación y el peso de cada decisión.

El CHAOS Report 2015 del Standish Group midió el resultado de 50.000 proyectos de software entre 2011 y 2015. Los proyectos pequeños salieron bien en el 61 % de los casos. Los más grandes, la categoría que Standish llama grand, en el 6 %. Los proyectos pequeños con metodología ágil fracasaron del todo en el 4 % de los casos. La conclusión de Standish es clara: a la mayoría de los proyectos de software les basta un equipo pequeño durante poco tiempo.

Hay un matiz que importa. Standish mide el tamaño del proyecto. El del proveedor queda fuera del estudio. Una gran agencia puede llevar un proyecto pequeño con cuatro personas. Un estudio pequeño puede aceptar un proyecto demasiado grande para él. Lo que respaldan los datos es mantener pequeño el proyecto. El proveedor se elige después, y la respuesta correcta es aquel cuyo equipo habitual coincide con el alcance que queda tras recortarlo.

Dónde gana un estudio pequeño

Un producto, un equipo, una hoja de ruta

Un MVP, una primera versión de pago o la reconstrucción de una web app son trabajo para un equipo de tres a seis personas. Con ese tamaño, quien está en la llamada comercial es quien está en el repositorio. Una pregunta hecha el lunes la contesta alguien que conoce el código, a menudo ese mismo día, sin intermediarios.

Diseño y código que tienen que ir a la par

Cuando el producto y su design system crecen juntos, cada traspaso entre un departamento de diseño y uno de desarrollo es una ocasión para que se separen. En un estudio pequeño, las mismas pocas personas dibujan la pantalla y escriben el componente, así que un cambio en un token o en un patrón llega a los dos sitios de una vez.

Presupuestos en los que se nota cada puesto

Lee la lista de puestos de cualquier propuesta y cuenta cuántos diseñan pantallas o escriben código. En un presupuesto de unos cientos de miles de euros, una capa de coordinación puede llevarse una parte que preferirías gastar en el producto. Un estudio pequeño, por cómo está hecho, tiene menos. Para las cifras, mira cuánto cuesta desarrollar un SaaS en 2026.

Continuidad después del lanzamiento

Quien desarrolló la versión 1.0 es quien arregla el primer bug que reportan y publica la 1.1. Nadie tiene que pasar el sistema a un equipo de mantenimiento que lo vio por primera vez la semana anterior.

Dónde gana una gran agencia

Líneas en paralelo con fecha fija

Web app, dos apps nativas, un pipeline de datos y una web de marketing, todo en marcha para una feria en marzo: son cinco líneas que cubrir a la vez. Un estudio pequeño tendría que ponerlas en fila, y en fila no llega a la fecha. Una agencia de 80 personas puede poner un equipo en cada línea la misma semana.

Compras que pide pruebas antes de empezar

Las grandes empresas suelen enviar un cuestionario de seguridad antes del primer taller. Algunas piden un informe SOC 2, que es una atestación según las normas de la AICPA sobre los Trust Services Criteria, con el criterio Security obligatorio en todos los informes. Otras piden un certificado ISO/IEC 27001, coberturas de seguro o cuentas auditadas. En servicios financieros el listón lo pone la ley: con el reglamento europeo DORA, aplicable desde el 17 de enero de 2025, bancos, aseguradoras y otras entidades financieras deben llevar un registro de todos sus contratos con proveedores de servicios TIC, y esos contratos deben prever estrategias de salida. Un estudio pequeño puede cumplir estos requisitos. Si tu equipo de seguridad necesita un informe ya hecho desde el primer día, pregúntalo antes de la presentación, porque conseguir uno lleva meses.

Guardias y relevos

Un producto que tiene que responder a una incidencia un domingo a las tres de la madrugada necesita turnos de guardia, y los turnos necesitan gente. Una gran agencia también absorbe las salidas: cuando alguien se va, entra un compañero con el mismo puesto.

Trabajo más allá del producto

Campañas, compra de medios, paneles de investigación en ocho países, traducción a veinte idiomas. Cuando el encargo va mucho más allá del diseño y el desarrollo, una gran agencia puede sustituir a varios proveedores pequeños y a la coordinación entre ellos.

Cuatro preguntas antes de firmar

1. ¿Cuántas líneas tienen que avanzar a la vez en los próximos seis meses? Una o dos apuntan a un estudio pequeño. Cuatro o más apuntan a una gran agencia, o a dividir el trabajo.
2. ¿Qué tiene que tener ya el proveedor antes de que compras firme? Pregúntaselo esta semana a los equipos de seguridad y legal, antes de la lista corta. Un informe que falta tumba un acuerdo tarde, tras semanas de talleres.
3. ¿Con quién hablarás cada semana, y esas personas diseñan o escriben código? Pide los nombres en la propuesta y luego pide conocerlos. En nuestra guía para contratar un estudio de product engineering están las preguntas para esa llamada.
4. Si la persona de referencia se fuera mañana, ¿qué te quedaría? La respuesta correcta es el código en un repositorio de tu empresa, documentación escrita y una cláusula de personas clave en el contrato. Las cláusulas que buscar están en ocho cláusulas a revisar en los contratos.

¿Se puede repartir el trabajo entre un estudio pequeño y una gran agencia?

Sí, y los datos del CHAOS van en esa dirección: el propio Standish aconseja partir los programas grandes en varios proyectos pequeños. Un reparto habitual deja el producto web principal y su design system a un estudio pequeño, y las apps nativas o la campaña a una estructura más grande. El precio del reparto es la integración. Nombra un único responsable del contrato de la API y otro de los design tokens, y dale a cada proveedor su propio SOW bajo un contrato marco, como se explica en SOW y MSA. Una fase de discovery corta y pagada es el sitio más barato para trazar esa frontera.

Dónde estamos nosotros

Somos un estudio pequeño, así que lee esta sección sabiéndolo. Aceptamos encargos en los que un solo equipo diseña y desarrolla un producto y sigue con él después del lanzamiento. Cuando un encargo pide muchos equipos en paralelo antes de una fecha fija, o documentos que tu departamento de compras tiene que ver el primer día, lo comprobamos en la primera llamada. Así los dos nos ahorramos una ronda de propuestas.