Tecnología

Estimador de líneas de código (LOC) y esfuerzo de desarrollo por proyecto

Q: ¿Cuántas líneas de código tiene una app móvil?

Una app móvil nativa de complejidad media tiene entre 30.000 y 80.000 LOC . Una app simple (login + 3-4 pantallas + API) puede estar en 15.000-30.000 LOC; una con funcionalidades avanzadas (geolocalización, pagos, push, cámara) puede superar las 100.000 LOC. Una app cross-platform con Flutter o React Native suele requerir entre un 20% y un 40% menos de código que la versión nativa equivalente.

Q: ¿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.

Q: ¿Qué es la Ley de Brooks y cómo afecta el plazo?

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 .

Q: ¿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. Las líneas de test 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.

Q: ¿Cómo impacta el lenguaje de programación en la estimación de LOC?

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. 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. Los frameworks modernos (Django, Laravel, Rails, Next.js) pueden reducir el LOC total de un proyecto en un 40-60%, impactando directamente en el esfuerzo estimado.

Q: ¿Cómo se usa esta estimación para calcular el costo de desarrollo?

El flujo es: persona-meses × costo mensual del desarrollador = costo total de desarrollo . 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. En Argentina (2025), un desarrollador semi-senior freelance cobra entre USD 2.000 y USD 4.000/mes; en relación de dependencia, el costo empleador incluye cargas sociales de ~1.5x el sueldo bruto.

Q: ¿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 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. Combinalo con una estimación de funcionalidades (story points o épicas) para que vean qué están comprando.

Calculá cuántas líneas de código tiene tu proyecto (app web, móvil, SaaS, e-commerce) y cuánto tarda en construirse. Resultados en LOC, persona-meses y meses calendario con factor Brooks.

Datos verificados · junio de 2026
Editado por Martín Rodríguez
Fórmula verificada con pruebas automatizadas
Cálculo privado en tu dispositivo

Proponer mejora

Calculadora Gratis · Privada

Datos actualizados: 15 abr 2026 · Fuente: COCOMO II — Software Cost Estimation Model (USC)

Editado por: Martín Rodríguez (política editorial )

Proponer mejora

🧮 Seguí calculando

Calculadora de Ganancia de Amplificador Operacional (Inversor y No Inversor)Ganancia 11× (20.8 dB). Inversor: -10×. Op-amps como LM358 (general), TL081 (audio), AD8656 (precisión).

¿Tenés una web? Incrustá esta calculadora gratis Gratis — copiá el código y pegalo en tu web Embeber en tu sitio

<iframe src="https://hacecuentas.com/embed/calculadora-codigo-lineas-estimacion-proyecto" width="100%" height="560" style="border:1px solid #e2e8f0;border-radius:12px;max-width:720px" loading="lazy" title="Estimador de líneas de código (LOC) y esfuerzo de desarrollo por proyecto"></iframe>
<p style="font-size:13px;text-align:center;margin:8px 0">Powered by <a href="https://hacecuentas.com" target="_blank" rel="noopener sponsored">Hacé Cuentas</a> — <a href="https://hacecuentas.com/calculadora-codigo-lineas-estimacion-proyecto" target="_blank" rel="noopener sponsored">Estimador de líneas de código (LOC) y esfuerzo de desarrollo por proyecto</a></p>

Ver preview →

Pegalo en tu sitio. Dejá el link de crédito — gracias por compartir. Más widgets →

¿Querés cambiar algo?Editá cualquier dato y volvé a calcular.

Resultado al instanteSe recalcula en tu navegador, sin recargar la página.

Rápida y transparente

Cómo usar esta calculadora

Usá los pasos de esta herramienta y revisá debajo la fórmula, los supuestos y sus límites.

Paso a paso

Seleccioná el tipo de proyectoElegí entre Landing page, App web, App móvil nativa, Plataforma SaaS o E-commerce según lo que querés estimar.

Elegí la complejidadSeleccioná Baja (pocas features, sin integraciones), Media (estándar, algunas integraciones) o Alta (muchas features, integraciones complejas).

Ingresá la cantidad de desarrolladoresEscribí cuántos devs full-time van a trabajar en el proyecto (mínimo 1, máximo 50).

Avisame cuando cambie este dato

Te mandamos un solo mail cuando COCOMO II — Software Cost Estimation Model (USC) publique el dato nuevo que usa esta calculadora. Nada más.

Gratis · Sin spam · Salís con un click

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? 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 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.
Una empresa quiere desarrollar un sistema interno de gestión de clientes con reportes. 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 sector público y necesita estimar el esfuerzo de un portal de trámites con autenticación, adjuntos y notificaciones. La estimación de ~50.000 LOC y 20 persona-meses sirve como base para el presupuesto oficial.

LOC estimadas por tipo de proyecto y complejidad

Tipo de proyecto	Complejidad baja	Complejidad media	Complejidad alta
Landing page	1.750 LOC	3.500 LOC	7.000 LOC
App web CRUD	15.000 LOC	30.000 LOC	60.000 LOC
App móvil nativa	25.000 LOC	50.000 LOC	100.000 LOC
E-commerce	40.000 LOC	80.000 LOC	160.000 LOC
Plataforma SaaS	100.000 LOC	200.000 LOC	400.000 LOC

Fuente: COCOMO II – USC / Steve McConnell, Software Estimation (Construx). Valores basados en datos empíricos de productividad: ~2.500 LOC productivas/mes por desarrollador (125 LOC/día × 20 días laborales).

Cómo funciona

Tiempo estimado con distintos tamaños de equipo

Persona-meses	1 dev	2 devs	3 devs	5 devs
6	6,3 meses	3,2 meses	2,2 meses	1,4 meses
12	12,6 meses	6,3 meses	4,3 meses	2,8 meses
32	33,6 meses	16,8 meses	11,3 meses	7,4 meses
80	84 meses	42 meses	28 meses	18,4 meses

La fórmula

LOC estimadas = LOC base × Factor complejidad
Persona-meses = LOC ÷ Productividad mensual (2.500 LOC/mes)
Meses calendario = Persona-meses ÷ Cantidad devs × Factor comunicación

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

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 laborales)	~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 y overhead de comunicación

> «Agregar gente a un proyecto atrasado lo atrasa más.» — Fred Brooks, The Mythical Man-Month (1975)

Duplicar el equipo no reduce el tiempo a la mitad. La comunicación crece con N×(N-1)/2 canales:

Tamaño del equipo	Overhead de comunicación
1–2 devs	+5 %
3–5 devs	+15 %
6–10 devs	+25 %
11–20 devs	+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 que importan en producción son: features entregadas, cobertura de tests y bugs por release.

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 × 1,05 overhead = ~6,3 meses calendario.

Una app web mediana con 2 desarrolladores lleva aproximadamente 6 meses. Con 3 devs baja a ~4 meses, pero agregar más personas no escala linealmente (Brooks's Law).

Preguntas frecuentes

¿Cuántas líneas de código tiene una app web típica?

Una app web de complejidad media (CRUD con dashboard, autenticación y algunas integraciones) tiene entre 20.000 y 60.000 LOC. Una app web simple puede estar en 10.000-25.000 LOC; una con lógica de negocio compleja puede superar las 100.000 LOC. Una SaaS madura con múltiples módulos suele tener entre 150.000 y 500.000 LOC. Para referencia: el kernel de Linux tiene ~30 millones de LOC; WordPress core ronda las 600.000 LOC.

¿Cuántas líneas de código tiene una app móvil?

Una app móvil nativa de complejidad media tiene entre 30.000 y 80.000 LOC. Una app simple (login + 3-4 pantallas + API) puede estar en 15.000-30.000 LOC; una con funcionalidades avanzadas (geolocalización, pagos, push, cámara) puede superar las 100.000 LOC. Una app cross-platform con Flutter o React Native suele requerir entre un 20% y un 40% menos de código que la versión nativa equivalente.

¿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.

¿Cuántas líneas productivas escribe un desarrollador por día?

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. La cifra de 125 LOC/día es un promedio razonable para estimaciones. A 20 días laborales por mes, eso equivale a ~2.500 LOC/mes.

¿Qué es la Ley de Brooks y cómo afecta el plazo?

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.

¿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. Las líneas de test 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.

¿Cómo impacta el lenguaje de programación en la estimación de LOC?

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. 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. Los frameworks modernos (Django, Laravel, Rails, Next.js) pueden reducir el LOC total de un proyecto en un 40-60%, impactando directamente en el esfuerzo estimado.

¿Cómo se usa esta estimación para calcular el costo de desarrollo?

El flujo es: persona-meses × costo mensual del desarrollador = costo total de desarrollo. 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. En Argentina (2025), un desarrollador semi-senior freelance cobra entre USD 2.000 y USD 4.000/mes; en relación de dependencia, el costo empleador incluye cargas sociales de ~1.5x el sueldo bruto.

¿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.

¿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 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. Combinalo con una estimación de funcionalidades (story points o épicas) para que vean qué están comprando.

¿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 externas, 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. 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 Story Points y Planning Poker?

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.

¿Cuánto tarda en construirse una plataforma SaaS?

Una plataforma SaaS de complejidad media tiene ~200.000 LOC, lo que equivale a 80 persona-meses de desarrollo. Con un equipo de 5 devs (overhead +15%), eso da ~18-19 meses calendario. Con 10 devs (overhead +25%), bajaría a ~10 meses. En la práctica, muchos SaaS lanzan un MVP reducido en 6-9 meses (~30.000-50.000 LOC) y agregan funcionalidades iterativamente. El total al cabo de 3 años de desarrollo puede superar fácilmente las 500.000 LOC incluyendo tests y herramientas internas.

Fuentes y referencias

Metodología y confianza

Editorial

Calculadora de tecnología con fórmula verificada automáticamente contra COCOMO II — Software Cost Estimation Model (USC), según nuestra política editorial y metodología.

Actualización

Actualizado: junio de 2026. Los parámetros se verifican periódicamente con las fuentes citadas.

Privacidad

Los cálculos corren 100% en tu navegador. No guardamos ni transmitimos tus datos.

Limitaciones

Resultados orientativos. Para decisiones críticas, consultá con un profesional.

📌 Cómo citar esta calculadora

Rodríguez, M. (2026). Estimador de líneas de código (LOC) y esfuerzo de desarrollo por proyecto. Hacé Cuentas. https://hacecuentas.com/calculadora-codigo-lineas-estimacion-proyecto

Contenido bajo licencia CC-BY 4.0 — reutilizable citando la fuente con enlace a Hacé Cuentas.

✉️ Reportar un error en esta calculadora