Calculadora Estimación de Esfuerzo de Desarrollo por Líneas de Código🌎 Actualizado mayo de 2026
Cuando un cliente pregunta «¿cuánto tarda hacer esto?», la respuesta honesta es: depende. Pero depende de cosas medibles. Esta calculadora aplica los principios del modelo COCOMO II (Constructive Cost Model, desarrollado en USC) junto con datos empíricos de productividad para darte una estimación de líneas de código (LOC) y esfuerzo en persona-meses según el tipo y la complejidad de tu proyecto. Algunos puntos de referencia para ubicarte: un sitio web informativo simple ronda las 2.000-8.000 LOC. Una app web con autenticación, dashboard y lógica de negocio: 20.000-60.000 LOC. Un SaaS maduro con integraciones y APIs: 150.000-500.000 LOC. Y un desarrollador senior, contando testing, code review, debugging y reuniones, produce en promedio 100-150 líneas productivas por día —no las que tipea, sino las que efectivamente quedan en producción. ¿Por qué esto importa en Argentina específicamente? Porque muchos proyectos freelance y de agencias se presupuestan «a ojo», sin metodología, y terminan en scope creep, retrasos y conflictos con el cliente. Tener una estimación basada en métricas te da un argumento técnico: no es capricho, es ingeniería de software. También es útil para armar contratos por hitos o para justificar timelines ante inversores o áreas de negocio que subestiman la complejidad técnica. Esta calculadora no reemplaza un análisis de requerimientos detallado, pero sí te da un piso razonable para arrancar la conversación con números encima de la mesa. Ingresás el tipo de proyecto, la complejidad y la cantidad de devs, y obtenés LOC estimadas, persona-meses de esfuerzo y meses calendario reales considerando coordinación de equipo.
Cuándo usar esta calculadora
- Una agencia de desarrollo en Buenos Aires necesita presupuestar una plataforma e-commerce con panel de administración. Ingresa 'app web compleja' + complejidad alta y obtiene ~80.000 LOC y 32 persona-meses, lo que con 4 devs se traduce en ~9 meses calendario.
- Un dev freelance recibe el pedido de una app móvil iOS con login, geolocalización y notificaciones push. La calc le devuelve ~40.000 LOC y 16 persona-meses, lo que le permite cotizar con fundamento en lugar de tirar un número al aire.
- Un CTO de una startup necesita justificar ante inversores por qué el MVP va a tardar 6 meses con un equipo de 3 devs. La estimación de ~22.000 LOC y 18 persona-meses valida el timeline con lógica técnica.
- Un PM de una empresa mediana tiene que presentar el roadmap anual. Usa la calc para estimar el esfuerzo de cada feature major del backlog y distribuir la capacidad del equipo de 5 devs durante los 12 meses.
- Un estudio contable argentino quiere desarrollar un sistema interno de gestión de clientes con reportes y exportación a AFIP. La calc estima ~15.000 LOC y 6 persona-meses, ayudando a decidir si conviene contratar un dev externo o usar una solución SaaS existente.
- Una empresa de logística necesita migrar un sistema legacy de 120.000 LOC a microservicios. La estimación le permite planificar el esfuerzo de reescritura en fases, priorizando los módulos críticos primero.
- Un dev líder quiere comparar si conviene hacer una app nativa iOS+Android (estimación: 70.000 LOC × 1.8 = ~126.000 LOC) versus una solución cross-platform con Flutter (~70.000 LOC × 1.2 = ~84.000 LOC), y la diferencia de esfuerzo impacta directamente en el costo.
- Una consultora IT arma una propuesta para el sector público argentino y necesita estimar el esfuerzo de un portal de trámites con autenticación AFIP/RENAPER, adjuntos y notificaciones. La estimación de ~50.000 LOC y 20 persona-meses sirve como base para el presupuesto oficial.
Ejemplo real: app web CRUD con dashboard, complejidad media, 2 devs
- Tipo: App web CRUD/dashboard → base ~30.000 LOC.
- Complejidad media: factor 1,0 → 30.000 LOC.
- Productividad: ~125 LOC/día/dev × 20 días/mes = 2.500 LOC/mes/dev.
- Persona-meses: 30.000 ÷ 2.500 = 12 persona-meses.
- Con 2 devs: 12 ÷ 2 = ~6 meses calendario.
Cómo funciona
2 min de lecturaLa estimación
Usamos LOC (Lines of Code) como proxy del esfuerzo, sabiendo que no es perfecto:
LOC estimadas = LOC base × Factor complejidad
Persona-meses = LOC ÷ Productividad mensual
Meses calendario = Persona-meses ÷ Cantidad devs × Factor comunicaciónLOC base por tipo de proyecto
| Tipo | LOC estimadas |
|---|---|
| Landing page | 2.000-5.000 |
| App web CRUD | 20.000-50.000 |
| App móvil nativa | 30.000-80.000 |
| SaaS completo | 100.000-500.000 |
| E-commerce | 50.000-150.000 |
Factor de complejidad
| Complejidad | Factor | Descripción |
|---|---|---|
| Baja | 0,5 | Pocas features, sin integraciones, UX simple |
| Media | 1,0 | Features estándar, 2-3 integraciones |
| Alta | 2,0 | Muchas features, integraciones complejas, alta seguridad |
Productividad real de un desarrollador
Según estudios de la industria (COCOMO, datos de Microsoft/Google):
| Métrica | Valor |
|---|---|
| LOC escritas por día | 50-200 |
| LOC productivas por día | 100-150 |
| LOC por día (con testing) | ~125 |
| LOC por mes (20 días) | ~2.500 |
Importante: "productivas" significa código que sobrevive al code review, testing y refactoring. Un dev puede tipear 500 líneas en un día pero solo 125 quedan en producción.
Ley de Brooks
> "Agregar gente a un proyecto atrasado lo atrasa más."
Duplicar el equipo no reduce el tiempo a la mitad. La comunicación crece cuadráticamente:
| Devs | Overhead comunicación |
|---|---|
| 1-2 | ~5 % |
| 3-5 | ~15 % |
| 6-10 | ~25 % |
| 11-20 | ~35 % |
LOC no mide calidad
Esta estimación es útil para planificación inicial, pero no confundas cantidad con calidad. 10.000 líneas bien escritas pueden resolver lo mismo que 50.000 mal escritas. Las métricas más importantes son: features entregadas, cobertura de tests y bugs por release.
Preguntas frecuentes
¿Qué son las líneas de código (LOC) y por qué se usan para estimar proyectos?
Las líneas de código (LOC o KLOC cuando se habla de miles) son la métrica más antigua y todavía más usada para dimensionar software. No miden calidad ni valor de negocio, pero sí dan una referencia de magnitud física del proyecto. El modelo COCOMO II, desarrollado por Barry Boehm en USC, usa KLOC como input principal para estimar esfuerzo en persona-meses. La lógica es simple: más líneas = más tiempo de escritura, testing, debugging y mantenimiento. Para un presupuesto inicial o una planificación de capacidad, es una proxy válida cuando no tenés requerimientos detallados. Lo importante es usarla como punto de partida, no como verdad absoluta.
¿Cuántas líneas de código tiene un proyecto típico según su tipo?
Los rangos empíricos más citados en la literatura de ingeniería de software son: sitio web informativo: 2.000-8.000 LOC; app web CRUD simple: 10.000-25.000 LOC; app web con lógica de negocio compleja: 40.000-120.000 LOC; app móvil simple: 15.000-30.000 LOC; app móvil compleja: 50.000-100.000 LOC; SaaS con múltiples módulos: 150.000-500.000 LOC. Para referencia, el kernel de Linux tiene ~30 millones de LOC, Windows ~50 millones. Un ERP empresarial como SAP maneja cientos de millones. Estos números no incluyen líneas de test, que pueden agregar un 50-100% adicional.
¿Cuántas líneas productivas escribe un desarrollador por día en la práctica?
El número más citado en la literatura (McConnell, DeMarco, Boehm) es 100-150 líneas productivas por día para un desarrollador con experiencia. Ese número ya descuenta reuniones, code review, debugging, escritura de tests, documentación y el inevitable tiempo perdido en interrupciones. Un dev júnior puede producir menos por el tiempo de aprendizaje; uno senior puede producir más por conocer atajos y patrones. En contexto argentino, hay que considerar además reuniones de daily, planificación de sprint y time zones si el equipo es distribuido con clientes en el exterior. La cifra de 125 LOC/día es un promedio razonable para estimaciones.
¿Qué es la Ley de Brooks y cómo afecta la estimación?
Fred Brooks lo enunció en 1975 en The Mythical Man-Month: agregar personas a un proyecto tardío lo retrasa más. La razón es que la comunicación entre N personas crece en N×(N-1)/2 canales. Un equipo de 2 personas tiene 1 canal de comunicación; uno de 5 tiene 10; uno de 10 tiene 45. Ese overhead consume tiempo real. La calculadora aplica un factor de comunicación: con 4 devs, los meses calendario no se dividen perfectamente por 4. En la práctica, el equipo óptimo para proyectos de mediana escala es 3-7 personas. Más de eso requiere división en equipos con interfaces bien definidas (como hacen Amazon con los 'two-pizza teams').
¿Las estimaciones incluyen el tiempo de testing y QA?
La productividad de ~125 LOC/día ya incluye el tiempo de unit testing, code review y debugging que hace el propio desarrollador. Lo que no incluye es QA separado (manual o automatizado), UAT con el cliente, ni las iteraciones por feedback. Si tu proyecto tiene un equipo de QA dedicado, eso es capacidad adicional. Las líneas de test (unit tests, integration tests, e2e) tampoco cuentan en el LOC estimado del proyecto: típicamente agregan un 50-100% más de código. Un proyecto de 30.000 LOC puede tener otros 20.000-30.000 LOC de tests. Es código real que lleva tiempo real.
¿Cómo impacta el lenguaje de programación en la estimación?
Significativamente. Los lenguajes de alto nivel (Python, Ruby, JavaScript) requieren entre 3 y 10 veces menos líneas que C o Assembly para la misma funcionalidad. Esto significa que una funcionalidad que en Java necesita 500 líneas, en Python puede resolverse en 150. Sin embargo, la productividad en LOC/día es similar entre lenguajes, porque lo que varía es la densidad funcional por línea. En la práctica, los frameworks modernos (Django, Laravel, Rails, Next.js) aceleran mucho el desarrollo inicial. La elección de stack puede reducir el LOC total de un proyecto en un 40-60%, impactando directamente en el esfuerzo estimado.
¿Qué pasa con los proyectos de migración o reescritura de sistemas legacy?
Las migraciones son sistemáticamente subestimadas. La regla general es que reescribir 100.000 LOC tarda tanto o más que haberlos escrito originalmente, porque hay que entender qué hace el sistema actual (sin documentación, frecuentemente), mantenerlo funcionando en paralelo y validar que la nueva versión hace exactamente lo mismo. El factor de dificultad de migración suele aplicarse multiplicador de 1.5x-2.5x sobre una estimación de proyecto nuevo equivalente. En el contexto argentino, muchas empresas medianas tienen sistemas legacy en Visual Basic, Clipper o Delphi que funcionan hace 20 años y nadie sabe exactamente cómo.
¿Cómo se usa esta estimación para armar un presupuesto en pesos o dólares?
El flujo es: persona-meses × costo mensual del desarrollador = costo total de desarrollo. En Argentina (2024-2025), un desarrollador semi-senior freelance cobra entre USD 2.000 y USD 4.000/mes. Uno en relación de dependencia tiene un costo empleador que incluye cargas sociales (aproximadamente 1.5x el sueldo bruto según la Ley 24.013 y convenios colectivos). Si la calc te devuelve 12 persona-meses y tu dev cuesta USD 3.000/mes, el costo de desarrollo es ~USD 36.000. A eso sumá overhead de PM, QA, infra y un buffer del 20-30% por imprevistos. El resultado es tu presupuesto base para discutir con el cliente.
¿Son confiables estas estimaciones para presentar a un cliente o inversor?
Como estimación de orden de magnitud (±50%), sí. Como compromiso contractual, no. La literatura de gestión de proyectos (McConnell, Wideband Delphi) recomienda siempre dar rangos, no números puntuales. Una forma correcta de presentarlo: 'estimamos entre 10 y 16 persona-meses según cómo evolucionen los requerimientos'. Ante inversores, es más útil que no tener ningún número. Ante clientes, combinalo con una estimación de funcionalidades (story points o épicas) para que vean qué están comprando. La calculadora es una herramienta de arranque, no un contrato.
¿Qué errores comunes se cometen al estimar proyectos de software?
Los más frecuentes son: 1) No incluir tiempo de requerimientos y diseño (puede ser 15-20% del proyecto total). 2) Asumir productividad de laboratorio sin considerar interrupciones, vacaciones y reuniones. 3) No agregar buffer para integraciones con terceros (APIs de AFIP, Mercado Pago, pasarelas de pago): siempre tardan más. 4) Subestimar la complejidad de los 'últimos' detalles: el 80% de las funcionalidades se hace en el 20% del tiempo, pero ese otro 20% lleva el 80% restante. 5) No contemplar scope creep: en proyectos sin control de cambios formal, los requerimientos crecen 20-40% durante el desarrollo.
¿Cómo se diferencia esta estimación de un Planning Poker o Story Points?
Son enfoques complementarios. Los story points y el planning poker (metodología ágil) estiman esfuerzo relativo entre tareas sin convertir directamente a tiempo. Son útiles cuando el equipo ya tiene velocidad histórica medida en sprints. La estimación por LOC y COCOMO es un enfoque top-down para proyectos nuevos donde no hay historial de velocidad. Lo ideal es usar ambos: LOC para la estimación inicial del proyecto completo, y story points para planificar sprint a sprint. A medida que avanzás y tenés velocidad real del equipo, la estimación LOC pierde relevancia y manda el dato empírico.
¿Esta calculadora sirve para presupuestar proyectos para el Estado argentino?
Puede ser un punto de partida, pero las contrataciones del Estado tienen sus propias reglas. La Ley 13.064 de Obras Públicas y el Decreto 1030/2016 de Contrataciones regulan los procesos de licitación. Para servicios de software, la modalidad más común es licitación pública o contratación directa según el monto. Las empresas deben acreditar antecedentes y el precio se justifica con una memoria de cálculo. En ese contexto, una estimación COCOMO documentada puede ser parte de la justificación técnica del precio ofertado. Los municipios y provincias tienen sus propias reglamentaciones, pero el esquema es similar a nivel federal.
Fuentes y referencias
Metodología y confianza
Contenido revisado por el equipo editorial de Hacé Cuentas, con apego a nuestra política editorial y metodología de cálculo.
Última revisión: 18 de mayo de 2026. Los parámetros fiscales, legales y datos se verifican periódicamente con las fuentes citadas.
Los cálculos corren 100% en tu navegador. No guardamos ni transmitimos tus datos. Leé nuestra política de privacidad.
Resultados orientativos. Para decisiones financieras, médicas o legales críticas, consultá con un profesional.