.svg)
¿Cuánto cuesta desarrollar software a medida? Nuestro estimador inteligente
¿Cuánto cuesta desarrollar una idea? La pregunta que casi todo el mundo responde mal
Hace poco hablé con el CEO de una proptech en fase pre-seed. No era uno de esos emprendedores de escuela de negocios, ex-Big Four y sin una cicatriz que contar, ni alguien que hubiera tenido el viento siempre a favor. Era un tipo hecho a sí mismo, con un historial de luchador envidiable… Llevaba muchos años trabajando en el sector inmobiliario y conocía perfectamente dónde se perdían el tiempo, el dinero y las oportunidades. Había identificado un problema real, hablado con clientes, analizado a la competencia y construido un prototipo bastante convincente. En definitiva, había hecho casi todo lo que se espera de un buen fundador… Solo le quedaba responder a una pregunta que, curiosamente, incluso para alguien que era un experto en su negocio, resultaba casi imposible contestar:
—Rafael, ¿cuánto cuesta desarrollar esto?
“Esto”, su proyecto, era una plataforma capaz de conectar a los diferentes actores del mercado inmobiliario, centralizar información, automatizar procesos, generar documentación e incorporar inteligencia artificial. Últimamente parece que da vergüenza desarrollar un software que no lleve IA. Una startup sin inteligencia artificial parece incompleta o, peor aún, “viejuna”… aunque en muchos casos no aporte ningún valor real al usuario y solo sirva para encarecer la solución.
Antes de hablar conmigo ya había solicitado varias propuestas, siguiendo además una condición impuesta por los futuros inversores: el equipo debía trabajar exclusivamente para él, admitiendo contratación directa, AOR u otros modelos que respetaran completamente su dirección y gestión. Una empresa aseguró que podía construir la plataforma con dos desarrolladores en unos meses utilizando una metodología tradicional. Otra presentó un presupuesto bastante más elevado con un equipo multidisciplinar trabajando bajo SCRUM y dirigido por un líder técnico propio. Una tercera ni siquiera quiso comprometerse con una cifra sin realizar antes una fase de análisis, definición de producto y arquitectura. Lo curioso es que todos habían recibido exactamente el mismo PowerPoint, las mismas condiciones de partida y la misma explicación del proyecto… y, aun así, los presupuestos oscilaban entre los 150.000 y los 500.000 euros y los plazos entre 4 meses y 12.
Su conclusión fue inmediata:
—Alguien está intentando aprovecharse de mí.
Mi respuesta fue algo menos tranquilizadora:
—Probablemente no. El problema es que cada proveedor está imaginando un producto diferente.
Y ahí comienza el verdadero problema de la estimación de software.
Cuando compras software, todavía no sabes exactamente qué estás comprando
Como este CEO venía del sector inmobiliario, intenté explicárselo con un ejemplo que conocía bien.
Cuando compras un inmueble puedes visitarlo, medirlo, estudiar su ubicación, comprobar su estado y compararlo con otros activos de la zona.
Cuando construyes un edificio existen planos, mediciones, materiales, normativa y procesos relativamente conocidos. Antes de comenzar la obra, un arquitecto ha definido qué se va a construir.
En software, cuando alguien solicita el primer presupuesto, normalmente no existe nada de eso.
Tenemos una idea. Algunas funcionalidades. Unas pantallas. Un documento. Y, con suerte, un prototipo en Figma donde todo funciona perfectamente...
Porque todavía no hace nada.
No existe una arquitectura definitiva. No conocemos todas las integraciones. No se ha decidido cómo se gestionarán los datos. No sabemos qué nivel de seguridad será necesario. Tampoco conocemos el volumen real de usuarios, el rendimiento esperado, las condiciones de disponibilidad o los problemas que aparecerán cuando el producto entre en contacto con clientes reales.
Y aparecerán...
Una estimación inicial no calcula el precio de un producto completamente definido. Intenta anticipar el coste de cientos de decisiones que todavía no se han tomado.
El error consiste en exigirle la misma precisión que tendría el presupuesto de una reforma.
Podemos realizar una estimación rigurosa. Podemos analizar riesgos. Podemos calcular una horquilla razonable. Pero no podemos adivinar el futuro...
Cómo se comparan los principales métodos de estimación de software
Antes de hablar de nuestro modelo, conviene poner en contexto las alternativas más habituales. No todas intentan resolver el mismo problema, ni parten del mismo nivel de información. Algunas estiman horas, otras tamaño funcional, otras dependen del consenso de un equipo... y casi ninguna analiza conjuntamente arquitectura, negocio y composición del squad.
La siguiente tabla resume sus principales diferencias.
Dos aplicaciones que hacen lo mismo... pero no cuestan lo mismo
Imaginemos dos plataformas proptech.
Las dos permiten registrar inmuebles, gestionar propietarios, almacenar documentación y consultar operaciones. Desde fuera parecen prácticamente iguales.
La primera está diseñada para validar el modelo de negocio con diez agencias inmobiliarias en Madrid. Puede apoyarse inicialmente en algunos procesos manuales, utilizar servicios externos y aceptar ciertos compromisos técnicos para llegar antes al mercado.
La segunda debe operar en cinco países, integrarse con diferentes CRMs y ERPs, gestionar información sensible, cumplir requisitos regulatorios, soportar miles de operaciones y permanecer disponible las veinticuatro horas.
Las dos tienen una pantalla de acceso. Las dos gestionan usuarios. Las dos almacenan documentos. Las dos muestran inmuebles. Pero no son el mismo producto.
Una es una herramienta para aprender. La otra es una infraestructura sobre la que funcionará una empresa.
El software no cuesta únicamente por lo que hace. Cuesta por las condiciones en las que debe hacerlo, por cuánto debe durar, por cómo deberá evolucionar y por las consecuencias que tendría que dejara de funcionar. Y esto no suele aparecer en el ppt del cliente ni en su lista de funcionalidades...
El mercado tiene respuestas para todos los gustos
Cuando un fundador intenta averiguar cuánto costará su producto, el mercado le ofrece diferentes respuestas.
Todas pueden ser válidas. Y todas pueden provocar un desastre cuando se utilizan sin comprender sus limitaciones.
1. El presupuesto cerrado
Es la alternativa favorita de muchos clientes. En especial en lo de perfil financiero o departamentos de compras.
Se entrega un documento con los requisitos, el proveedor devuelve una cifra y ambas partes firman un contrato. El cliente cree que ha eliminado la incertidumbre. El proveedor cree que ha comprendido el alcance. Es una buena manera de llamar a Murphi… el de la ley… no la de Charles Bronson
Durante unas semanas todos duermen tranquilos… Después comienza el proyecto:
Aparecen necesidades que nadie había contemplado. Algunas funcionalidades son más complejas de lo esperado. Las integraciones no funcionan como prometía la documentación. Los usuarios opinan. El mercado cambia. Y el fundador descubre que aquello que pidió hace cuatro meses aún no existe, y lo que es peor: hay cosas que ya no son como él las definió.
Entonces comienza el verdadero desarrollo… El desarrollo del contrato.
¿Eso estaba incluido? ¿Es un cambio de alcance? ¿Quién paga la modificación? ¿La aplicación móvil estaba incluida o simplemente se dijo que la plataforma debía poder utilizarse desde un teléfono?
Un presupuesto cerrado puede funcionar cuando el alcance está bien definido y es poco probable que cambie. Pero una startup pre-seed se encuentra precisamente en la situación contraria. Está aprendiendo qué producto debe construir.
Como explicamos en nuestra guía sobre la metodología de squads, los modelos cerrados pueden proporcionar cierta previsibilidad presupuestaria, pero tienen dificultades para absorber los cambios inevitables de un producto digital.
Cerrar demasiado pronto aquello que todavía no comprendemos es una manera muy eficaz de comprar tranquilidad durante los primeros meses...
Y problemas durante los siguientes.
2. Time & Material: el outsourcing tradicional
La segunda alternativa es el modelo Time & Material, habitual en el outsourcing tradicional.
El cliente paga por el tiempo consumido por el equipo: horas, jornadas, sprints o meses.
Es un modelo más flexible que el presupuesto cerrado, porque permite cambiar prioridades y adaptar el alcance. También tiene algunos pequeños inconvenientes que ya nombramos en el blog en el post “AOR vs Outsourcing para talento técnico remoto”, el principal: demasiadas empresas han descubierto que es mucho más rentable vender horas que resolver problemas…
El cliente mira las facturas. El proveedor mira el backlog. Y el backlog siempre parece tener espacio para una funcionalidad más...
El problema del outsourcing tradicional no es únicamente la facturación por tiempo. También es la separación que suele producirse entre quien gestiona el negocio y quien gestiona el equipo.
En un outsourcing correctamente planteado, el proveedor debe organizar a sus profesionales, asumir la dirección del equipo y responsabilizarse del servicio o del resultado. El cliente define los objetivos, las prioridades y los criterios de aceptación.
Cuando el proveedor se limita a “colocar” desarrolladores y el cliente termina organizando su trabajo diario, tenemos lo peor de los dos modelos...
Intermediación, poca transparencia y responsabilidades difusas… pueden acabar en un disgusto.
Pagar 2.000 horas no garantiza recibir 2.000 horas de valor...
EOR y AOR: alternativas mejores para muchas startups
Una startup no siempre necesita entregar el control de su producto a una consultora.
En muchos casos necesita acceder a talento especializado, conservar la gestión y estructurar correctamente la relación con profesionales remotos.
Un EOR, Employer of Record, permite contratar a un profesional como empleado en un país donde la startup no dispone de una entidad local. Es una solución adecuada cuando existe una relación laboral real: dedicación estable, dependencia, continuidad e integración en la organización.
Puede ser la solución correcta...
Pero no siempre es la más sencilla para una startup.
El AOR, Agent of Record, está pensado para gestionar relaciones con profesionales independientes, internacionales o no. La startup mantiene la gestión del producto y del equipo. El profesional mantiene su autonomía. Y el AOR proporciona la estructura contractual y administrativa necesaria.
Para una startup que necesita incorporar talento tecnológico internacional de forma flexible, el AOR suele resultar más sencillo y eficaz que el outsourcing tradicional o un EOR innecesariamente complejo.
Pero ningún nombre comercial transforma la naturaleza de una relación...
La elección debe depender de cómo será realmente la relación de trabajo, no de la casilla que resulte más barata.
3. La solución del “atrevido”: Contratar uno o dos desarrolladores
Esta suele ser la solución favorita de una startup con un presupuesto limitado:
—”Empecemos con uno o dos programadores y ya…. ya iremos creciendo.”
El planteamiento resulta curioso.
Cuando alguien construye una casa entiende perfectamente que necesita un arquitecto, un constructor, albañiles, electricistas y fontaneros. Nadie lo discute. Y menos el usuario o comprador de la vivienda.
Nadie le dice al albañil:
—Como eres muy bueno colocando ladrillos, diseña también la estructura, instala las tuberías, prepara el cuadro eléctrico y calcula la eficiencia energética...
En software sí.
Contratamos a uno o dos desarrolladores y esperamos que definan el producto, diseñen la experiencia de usuario, seleccionen la arquitectura, programen el frontend y el backend, configuren la infraestructura, automaticen los despliegues, garanticen la seguridad, prueben la aplicación y participen en las decisiones estratégicas del negocio.
“Y, ya que estamos...Que sean baratos.”
El problema no es comenzar con un equipo pequeño. El problema es comenzar con un equipo incompleto y esperar que las responsabilidades que faltan desaparezcan solas...
Como explicamos en How to Build a Development Team in 2026: The Playbook for Startups, una startup no debe seleccionar únicamente personas. Debe estructurar responsabilidades: Producto. Arquitectura. Desarrollo. Experiencia de usuario. Calidad. Infraestructura. Seguridad.
No todas requieren una persona dedicada a tiempo completo. Pero todas existen...
Aunque no aparezcan en el presupuesto inicial.
4. La calculadora online
Otra alternativa consiste en utilizar una calculadora online.
Seleccionamos “aplicación móvil”. Indicamos el número de pantallas. Marcamos las casillas de pagos, notificaciones, geolocalización e inteligencia artificial. Pulsamos un botón...
Y recibimos un presupuesto. Rápido. Limpio. Sin reuniones.
El equivalente tecnológico a calcular el coste de un edificio preguntando únicamente cuántas habitaciones tendrá.
Algunas calculadoras asignan un número medio de horas a cada funcionalidad. Otras comparan el proyecto con aplicaciones anteriores. Y otras utilizan métodos más elaborados, como los puntos de función.
El análisis de puntos de función es una técnica reconocida para medir el tamaño funcional de una aplicación a partir de aquello que el sistema proporciona al usuario. Analiza entradas, salidas, consultas, datos internos e interfaces externas.
Es un método mucho más serio que contar pantallas. Permite comparar proyectos, analizar productividad y construir modelos históricos.
Pero también tiene limitaciones.
Dos sistemas con un tamaño funcional similar pueden necesitar arquitecturas y niveles de ingeniería radicalmente diferentes.
Los puntos de función ayudan a medir qué debe hacer el sistema. Pero no siempre reflejan por completo cómo debe hacerlo, en qué entorno funcionará, qué nivel de seguridad necesita, cuánto deberá escalar o qué riesgos técnicos existen.
Y ahí suele esconderse buena parte del presupuesto...
El error más frecuente: calcular recursos antes de entender el producto
Nuestro querido CEO proptech había intentado calcular cuántos desarrolladores necesitaba antes de comprender qué producto iba a construir.
Dos desarrolladores durante cuatro meses. Dos personas multiplicadas por cuatro meses y por un coste mensual.
La cuenta era sencilla… El producto no.
Antes de calcular los recursos necesitamos comprender el alcance, las integraciones, el nivel de calidad, las restricciones, el calendario y la capacidad del cliente para tomar decisiones.
También necesitamos hablar de arquitectura.
Porque no es lo mismo construir un sistema con Java que desarrollar una interfaz utilizando React. De hecho, Java y React ni siquiera resuelven el mismo tipo de problema...
Hay que decidir cómo se dividirá el sistema, qué partes estarán en el frontend, qué servicios existirán en el backend, cómo se almacenarán los datos, qué componentes serán propios, qué servicios se contratarán a terceros, cómo se desplegará, cómo se probará, cómo se protegerá y cómo crecerá.
Los lenguajes, frameworks, librerías y plataformas elegidos afectan al rendimiento, al mantenimiento, a la seguridad, a los despliegues y a los profesionales que necesitaremos incorporar.
También afectan al presupuesto.
Una arquitectura demasiado simple puede obligarnos a reconstruir el producto. Una arquitectura excesivamente sofisticada puede conseguir que el MVP necesite el equipo técnico de un banco internacional...
Elegir correctamente puede representar una diferencia enorme en tiempo, costes, mantenimiento y disgustos.
Y los disgustos también deberían incluirse en las estimaciones...
Nuestra propuesta
Cuando comenzamos a trabajar en el estimador de Squadmakers no queríamos construir otra calculadora de pantallas, funcionalidades y horas.
Queríamos trasladar a una herramienta las preguntas que haría un CTO, un arquitecto o un responsable de producto con experiencia antes de comprometer una inversión.
El modelo debía analizar el tipo de producto, su fase, el alcance, las integraciones, el nivel de ingeniería, las restricciones temporales y la capacidad del cliente para participar en las decisiones.
También debía proponer una composición de equipo.
No únicamente cuántas personas hacen falta...
Sino qué responsabilidades deben cubrirse y cuándo deben intervenir.
Porque la unidad correcta para pensar un proyecto no siempre es el desarrollador individual. En muchas ocasiones es el squad: un equipo pequeño, multidisciplinar, autónomo y orientado a una misión concreta.
En nuestra guía completa sobre la metodología de squads explicamos por qué la composición, la autonomía y la responsabilidad sobre el resultado son más importantes que limitarse a reunir perfiles técnicos.
El cliente no necesita necesariamente más personas.
Necesita la combinación adecuada.
Primero entendemos la complejidad
Nuestro modelo comienza intentando comprender qué hace complejo el proyecto: el tipo de producto, la fase del negocio, el alcance funcional, las integraciones, el nivel de ingeniería, las restricciones temporales y el conocimiento y dedicación del cliente.
Una pantalla aparentemente sencilla puede implicar validaciones, permisos, comunicaciones, pagos, auditoría e integraciones con varios sistemas.
Lo que ve el usuario casi nunca representa todo el trabajo.
Y la frase “tienen una API” no significa necesariamente que esté bien diseñada, documentada o disponible...
Cuando el cliente no dispone de un CTO o de un Product Manager experimentado, alguien debe cubrir esa función.
No incluirla en el presupuesto no consigue que desaparezca...
Solo consigue que aparezca más tarde convertida en retrasos, errores y cambios de alcance.
Aquí entra también el papel del Enabling Team: especialistas sénior en arquitectura, DevOps, QA, ciberseguridad, producto o experiencia de usuario que ayudan al squad cuando necesita conocimientos concretos, sin obligar a incorporar todos esos perfiles a tiempo completo.
No se trata de llenar el proyecto de jefes...
Se trata de conseguir que las decisiones importantes las tomen personas que sepan tomarlas.
La inteligencia artificial que hemos aplicado
Podríamos haber conectado un modelo generativo, pedir al cliente que describiera su idea y devolver una cifra con dos decimales.
Habría parecido muy inteligente...
Pero nadie podría explicar por qué el resultado era 180.000 euros y no 120.000.
Para una decisión que puede condicionar la supervivencia de una startup, “lo ha dicho la IA” no nos parece una explicación suficiente.
Por eso, nuestra solución se basa en árboles de decisión supervisados por expertos.
Cada respuesta modifica el recorrido del análisis. El tipo de producto abre determinadas necesidades. Las integraciones incrementan la complejidad. Los requisitos de seguridad modifican el esfuerzo. La urgencia puede alterar la composición del equipo. La madurez del cliente determina cuánto acompañamiento será necesario.
El resultado no aparece por generación espontánea.
Podemos reconstruir el razonamiento que conduce hasta la estimación. Podemos explicar qué factores incrementan el coste, qué decisiones amplían el plazo, qué riesgos requieren perfiles especializados y qué cambios permitirían reducir la inversión.
La IA no debería limitarse a proporcionar respuestas.
Debería ayudarnos a comprenderlas...
Una solución basada en 29 años de experiencia
El conocimiento que alimenta nuestro modelo no procede únicamente de los proyectos desarrollados por Squadmakers.
También se basa en mi participación en cientos de proyectos a lo largo de 29 años de experiencia profesional.
He trabajado como ingeniero, responsable de desarrollo, CTO, director de tecnología, emprendedor, mentor y asesor de startups.
Eso me ha permitido observar los proyectos desde perspectivas muy diferentes: la del desarrollador que recibe unos requisitos, la del arquitecto que debe tomar decisiones técnicas, la del responsable que tiene que coordinar al equipo, la del CEO que controla el presupuesto y la del emprendedor que descubre que su runway no entiende de retrasos...
A esta experiencia se suma nuestra colaboración con incubadoras y ecosistemas de emprendimiento, además de los proyectos personales que mentorizo habitualmente.
Cada proyecto aporta nuevos datos: qué integración resultó más compleja, qué funcionalidad necesitó menos esfuerzo, qué perfiles fueron realmente necesarios, dónde aparecieron los bloqueos, qué decisiones redujeron el tiempo y qué supuestos iniciales estaban equivocados.
Después, los expertos revisan las diferencias entre la estimación y la realidad, analizan sus causas y deciden qué aprendizaje puede incorporarse al modelo.
Los proyectos anteriores sirven para descubrir patrones. La experiencia humana sirve para interpretarlos.
Y el sistema aprende de esa combinación...
Después de 29 años dirigiendo proyectos, formando equipos y acompañando a startups, hemos aprendido que una buena estimación no nace de una fórmula aislada, sino de conectar negocio, arquitectura, riesgos y personas. La siguiente tabla resume cómo ese conocimiento acumulado se transforma en capacidades concretas dentro del estimador de Squadmakers.
Por qué ofrecemos una horquilla
A muchos clientes les gustaría recibir una respuesta exacta:
El proyecto costará 127.450 euros y estará terminado el 14 de marzo a las 11:35.
Sería fantástico. También sería mentira.
Al comienzo de un proyecto existen muchas decisiones pendientes. A medida que se define el producto, se selecciona la arquitectura, se estudian las integraciones y se concreta el alcance, la incertidumbre disminuye. Por eso ofrecemos una horquilla.
No es una forma de evitar el compromiso. Es una representación honesta de aquello que conocemos y de aquello que todavía no sabemos.
La estimación no elimina la incertidumbre. La hace visible...
Y aquello que es visible puede gestionarse.
La respuesta habitual de nuestros clientes
Cuando mostramos el resultado del estimador, la reacción más habitual no suele ser:
—Es exactamente lo que había calculado.
Normalmente escuchamos:
—Pensaba que costaría bastante menos.
Y, casi inmediatamente:
—También pensaba que podría hacerse con menos personas.
Es una reacción completamente lógica.
Desde fuera, el producto se percibe como una lista de funcionalidades: un registro, un panel, un buscador, un sistema de pagos, una integración y un módulo de inteligencia artificial.
Pero el esfuerzo invisible no aparece en esa lista.
La arquitectura. La infraestructura. Los permisos. Las pruebas. La seguridad. Los despliegues. La observabilidad. La documentación. La revisión del código. La coordinación. La gestión del producto. La traducción de necesidades de negocio a decisiones técnicas.
Y todo aquello que todavía no se ha pensado...
Cuando el cliente comprende todos esos elementos, la conversación cambia.
No le estamos diciendo: “Esto es lo que debes gastar obligatoriamente”.
Le estamos diciendo: “Este es el producto que nos has descrito. Estas son sus principales fuentes de complejidad. Estas son las decisiones que están impulsando el coste. Y estas son las alternativas que tenemos para reducirlo”.
Entonces comienza la conversación realmente útil.
Estimar también sirve para construir menos
Una buena estimación no debe limitarse a decir cuánto cuesta una idea.
Debe ayudar a hacerla viable.
Podemos descubrir que una integración prevista para la primera versión puede realizarse manualmente durante unos meses. Que no necesitamos aplicaciones nativas desde el primer día. Que una funcionalidad solo aportará valor cuando exista una masa crítica de usuarios. Que la expansión a diez países puede esperar. Que un proceso completamente automatizado puede comenzar siendo asistido. Que determinada inteligencia artificial puede sustituirse inicialmente por una buena regla de negocio...
En una startup, construir menos no siempre significa renunciar. Muchas veces significa priorizar.
Eliminar funcionalidades al azar abarata el proyecto. Reducir el alcance con criterio mejora el proyecto.
No es lo mismo...
El desenlace de nuestra proptech
Volvamos al CEO con el que comenzamos.
La cifra que tenía en mente era inferior a nuestra horquilla. También pensaba que podía comenzar con menos recursos.
No estaba equivocado porque desconociera su negocio. Conocía perfectamente el sector inmobiliario.
Lo que todavía no conocía era la estructura técnica necesaria para convertir su experiencia en un producto digital.
La solución no fue convencerle de que gastara más.
Fue ayudarle a construir menos.
Reducimos el alcance inicial. Pospusimos algunas integraciones. Convertimos determinados procesos automáticos en operaciones asistidas. Definimos qué hipótesis debían validarse primero. Y reorganizamos el equipo alrededor de esas prioridades.
El presupuesto dejó de ser una cifra...Y se convirtió en un mapa de decisiones.
La pregunta nunca fue cuánto cuesta
Después de 29 años participando en proyectos tecnológicos, creando empresas, dirigiendo equipos y asesorando a startups, he aprendido que cuando un CEO pregunta cuánto cuesta desarrollar una idea casi nunca está buscando únicamente un número.
Está intentando responder preguntas más importantes:
¿Puedo permitírmelo? ¿Estoy intentando construir demasiado? ¿Qué riesgos no estoy viendo? ¿Qué equipo necesito? ¿Qué arquitectura tiene sentido? ¿Qué puedo dejar para más adelante? ¿Dónde merece la pena invertir? ¿Esta idea puede convertirse realmente en un producto?
Una calculadora puede devolver una cifra. Un proveedor puede entregar un presupuesto. Un desarrollador puede estimar sus horas.
Pero una buena estimación debe hacer algo más. Debe convertir la incertidumbre en decisiones.
Porque el coste de desarrollar una idea no depende únicamente de sus funcionalidades. Depende del problema que resuelve, de cómo debe funcionar, de la arquitectura que elegimos, del equipo que la construye y de cuánto estamos dispuestos a aprender antes de equivocarnos.
El software nunca ha sido únicamente una cuestión de líneas de código. Siempre ha sido una cuestión de decisiones...
Y las decisiones más caras suelen ser aquellas que tomamos demasiado pronto, cuando todavía creemos que tenemos todas las respuestas.
Por tanto un estimador es útil, no por la exactitud del dato sino por el proceso mental de analizar el proyecto con una metodología que permite indicar un orden de magnitud, comprender el proceso de creación de un producto, y saber tomar decisiones que afectan de lleno a la viabilidad del proyecto. Os invitamos a usarlo, está disponible de forma gratuita en nuestra web https://challenge.squadmakers.com/estimador solo os pedimos que si quereis que analicemos los resultados juntos nos deis vuestros datos. Además, al estar basado en IA, podemos ir mejorando los resultados con vuestro feedback.
