La pregunta "¿cuántos desarrolladores necesito?" suele esconder otra peor: "¿cuánto cuesta lo que quiero hacer?". Si dimensionas el equipo solo en función del presupuesto, acabas con personas que no encajan con el producto. Si lo dimensionas solo por el alcance funcional, ignoras lo que la arquitectura realmente requiere para sostenerse. El cálculo correcto cruza ambas variables.
En Nirmana hemos dimensionado equipos para proyectos como Bracelit (pagos NFC en eventos en directo, 25M€ procesados) y Wegow (plataforma musical con 4M+ registrados), y la conclusión repetida es siempre la misma: el error caro no es contratar pocas personas, es contratar gente que no encaja con la arquitectura o la fase del producto.
Para complementar, lee también qué perfiles contratar según el tamaño del producto y, si dudas entre construir internamente o externalizar parte del desarrollo, subcontratación vs equipo interno. Si el sistema ya está en producción y no sabes si lo que falla es el equipo o el diseño técnico, conviene empezar por una auditoría de software.
01Factores clave para dimensionar un equipo de software
Antes de calcular el tamaño del equipo, debes considerar:
- Alcance del proyecto: Funcionalidades, complejidad, integraciones
- Plazos: Fecha de lanzamiento, hitos críticos
- Presupuesto: Recursos disponibles
- Experiencia del equipo: Seniority y conocimiento del dominio
- Tecnologías: Stack tecnológico y curva de aprendizaje
- Calidad requerida: Nivel de testing, documentación, seguridad
02Fórmula básica: Story Points y velocidad
La metodología más utilizada para dimensionar equipos se basa en Story Points y la velocidad del equipo:
Los Story Points son una unidad de medida relativa que combina complejidad, esfuerzo y riesgo. Un desarrollador junior puede tardar 8 horas en una tarea de 2 puntos, mientras que un senior puede hacerla en 2 horas. Escala común de Fibonacci:
- 1 punto: Tarea trivial (1-2 horas)
- 2 puntos: Tarea simple (medio día)
- 3 puntos: Tarea estándar (1 día)
- 5 puntos: Tarea compleja (2-3 días)
- 8 puntos: Tarea muy compleja (1 semana)
- 13+ puntos: Debe dividirse en tareas más pequeñas
03Dimensionamiento por tamaño de proyecto
MVP o Prototipo (1-3 personas)
- Alcance: 1-3 meses, funcionalidades core
- Perfiles: 1 Full-stack Senior + 1-2 desarrolladores
- Story Points estimados: 50-100 puntos
Producto Mínimo Viable Completo (3-6 personas)
- Alcance: 3-6 meses, múltiples funcionalidades
- Perfiles: 1 Tech Lead + 2-3 Backend + 1-2 Frontend
- Story Points estimados: 150-300 puntos
Producto Enterprise (6-15 personas)
- Alcance: 6-12+ meses, múltiples módulos complejos
- Perfiles: 1 CTO/Tech Lead + 4-6 Backend + 3-5 Frontend + 1-2 DevOps + 1 QA
- Story Points estimados: 500-1000+ puntos
04La arquitectura define el tamaño del equipo, no al revés
Antes de calcular cuántas personas necesitas, mira la arquitectura del producto. Un monolito modular bien estructurado no requiere el mismo equipo que una arquitectura de microservicios distribuidos, ni que un sistema de eventos en tiempo real. Cuando construimos la plataforma de Bracelit, la decisión arquitectónica de mantener un monolito Laravel en backend (en lugar de partir en microservicios prematuramente) nos permitió operar con un equipo deliberadamente pequeño durante años.
La regla práctica: dimensiona el equipo sobre la arquitectura que ya tienes o sobre la que vas a tener en 12 meses, no sobre la que tendrías en un mundo ideal. Si tienes dudas sobre si tu diseño técnico está pidiendo el equipo que estás dimensionando, conviene revisar el diseño de arquitectura antes de seguir contratando.
05La ley de Brooks: añadir personas a un proyecto retrasado lo retrasa más
Añadir más desarrolladores no siempre acelera el proyecto. Existe un punto óptimo donde añadir más personas reduce la productividad debido a:
- Costes de comunicación: Más personas = más reuniones y coordinación
- Curva de aprendizaje: Nuevos miembros necesitan tiempo para ser productivos
- Deuda técnica: Más desarrolladores pueden crear más deuda si no hay buenas prácticas
- Conflictos de código: Más merge conflicts y problemas de sincronización
Para la mayoría de proyectos, el punto óptimo está entre 4-8 desarrolladores por equipo. Equipos más grandes deben dividirse en squads o equipos independientes.
06Velocidad por perfil
- Desarrollador Junior: 5-10 puntos/sprint (2 semanas)
- Desarrollador Mid-level: 10-15 puntos/sprint
- Desarrollador Senior: 15-25 puntos/sprint
- Tech Lead: 10-15 puntos/sprint (dedica tiempo a gestión)
07Cálculo práctico: ejemplo real
Escenario: plataforma e-commerce con catálogo, carrito, checkout, panel admin e integración pasarela de pago. Plazo: 4 meses (8 sprints de 2 semanas). Story Points estimados: 200 puntos.
Equipo necesario: 25 puntos/sprint ÷ 15 puntos/sprint por senior = 1,67 seniors
→ Recomendación: 2 desarrolladores senior o 1 senior + 2 mid-level
Siempre añade un 20-30% de buffer para imprevistos, bugs, cambios de requisitos y tiempo de onboarding. En el ejemplo anterior, necesitarías realmente 240-260 puntos.
08Errores comunes al dimensionar equipos
- Subestimar la complejidad. Siempre multiplica tus estimaciones iniciales por 1,5-2x para tener un margen realista.
- No considerar el onboarding. Los nuevos desarrolladores necesitan 2-4 semanas para ser productivos. En Wegow, tras la pandemia, nos costó tres meses recuperar la velocidad anterior, no por falta de talento sino por la mecánica natural del onboarding en una plataforma con varios años de código encima.
- Ignorar la deuda técnica. Si el proyecto tiene deuda técnica o código legacy, necesitarás más tiempo y desarrolladores experimentados.
- Olvidar la gestión. Un Tech Lead o Project Manager no desarrolla a tiempo completo. Si tu Tech Lead también desarrolla, cuenta con un 50-70% de su tiempo para desarrollo.
09Preguntas frecuentes
¿Cuántos desarrolladores necesita una startup en fase MVP?
Para un MVP típico (3-6 meses, funcionalidad core), entre 1 y 3 desarrolladores. Lo ideal es 1 senior full-stack que tome decisiones técnicas y 1-2 mid-level que ejecuten. Si vais muy justos de presupuesto, un único senior puede ejecutar el MVP solo en 3-4 meses. Si necesitáis criterio técnico pero no hay senior interno, conviene añadir un CTO fractional a tiempo parcial.
¿Es mejor un equipo de 2 seniors o de 4 juniors?
En la mayoría de casos, 2 seniors. Su productividad combinada es similar pero el código que generan es más mantenible, las decisiones técnicas son mejores y no requieren mentoría continua. Los juniors aportan valor cuando hay seniority por encima que pueda dirigirlos sistemáticamente; sin esa estructura, generan más deuda técnica que valor.
¿Cuándo deberíamos contratar un Tech Lead?
Cuando el equipo supera los 3 desarrolladores, las decisiones técnicas empiezan a fragmentarse y aparecen inconsistencias en el código. El Tech Lead dedica entre el 30-50% de su tiempo a gestión, revisión y coordinación, así que su productividad como developer puro baja, pero el equipo entero gana en calidad y velocidad.
¿Cuál es el tamaño ideal de un equipo de software?
La regla práctica es la "two-pizza team" de Amazon: un equipo que pueda alimentarse con dos pizzas, aproximadamente entre 4 y 8 personas. Por encima de 8, los costes de comunicación aumentan exponencialmente y conviene dividir en squads independientes con ámbitos claros.
¿Cuánto cuesta un equipo de desarrollo de software en España en 2026?
Para un equipo medio (1 Tech Lead + 3 desarrolladores + 1 QA part-time), el coste anual oscila entre 280.000 € y 420.000 € contando salarios brutos, seguridad social y beneficios. Para una startup en fase seed, este nivel suele ser inviable y conviene combinar equipo interno mínimo + subcontratación de proyectos IT para escalar de forma flexible.
¿Cómo puedo estimar Story Points si nunca lo he hecho antes?
La técnica más fiable es comparar con tareas que ya conozcáis. Tomad una tarea pequeña conocida y asignadle "1 punto". Luego comparad cada tarea nueva con esa: ¿es el doble de compleja? 2 puntos. ¿Cinco veces? 5 puntos. Después de 2-3 sprints, vuestra escala se calibra sola con datos reales de velocidad.
Dimensionar un equipo de software es más arte que ciencia, pero con metodología y experiencia se hacen estimaciones precisas. La clave está en cruzar cuatro variables en el orden correcto: qué arquitectura sostiene tu producto hoy y en 12 meses, qué alcance funcional real tienes, qué velocidad puedes esperar según seniority y dominio, y qué buffer de imprevistos asumes (mínimo 25%).
Si quieres una segunda opinión antes de mover el equipo, en Nirmana acompañamos a startups en estas decisiones. Hablemos.
