Un fundador me llamó en noviembre de 2024, dos semanas antes de Navidad, absolutamente furioso. Una agencia web le había cotizado £14,000 por un panel de control de logística personalizado. Él había firmado. Seis meses después llegó la factura final por £61,000. Nadie le había mentido, técnicamente. Pero nadie le había dicho la verdad tampoco — porque nadie había hecho realmente el trabajo de estimar correctamente antes de tomar su dinero.
He estado construyendo software durante más de doce años. Seahawk sola ha entregado más de 5,000 sitios y aplicaciones. Y el punto de falla más consistente que veo — con fundadores, con freelancers, con agencias cotizando proyectos — es que nadie tiene una forma rigurosa de estimar costo antes de que se escriba una línea de código. La gente adivina. Se anclan en vibraciones. Usan el proyecto anterior como punto de referencia sin verificar si era remotamente comparable.
Entonces. Aquí está el marco que realmente uso. No una plantilla de hoja de cálculo con celdas de marcador de posición. Un modelo mental real, con números actuales de 2026, herramientas específicas, y las advertencias que importan.
---
Por Qué la Mayoría de las Cotizaciones de Software son Ficción
El problema no es la deshonestidad (usualmente). Es que la estimación de software es genuinamente difícil, y la mayoría de las personas subestima cuánto — así que recurren a atajos que parecen rigurosos pero no lo son.howhard — so they reach for shortcuts that feel like rigour but aren't.
Un desarrollador te da un número basado en su intuición. Una agencia multiplica su tarifa diaria por una cantidad estimada de sprints. Un freelancer mira un proyecto similar en Upwork y trabaja hacia atrás. Ninguno de estos enfoques es exactamente incorrecto, pero ninguno contabiliza los verdaderos factores de costo: complejidad de integración, latencia en las decisiones del cliente, scope creep en funciones que parecían menores, overhead de testing, y el asesino silencioso — setup de ambiente y DevOps que nadie presupuesta.
En 2021 estaba ejecutando un proyecto para un cliente de property-tech en Manchester. Bastante simple en el papel: un portal de inquilinos con cargas de documentos, seguimiento de renta, y un flujo de solicitudes de mantenimiento. La estimación inicial fue de £28,000. Habíamos hecho builds similares. Pero este cliente estaba usando un sistema de gestión de propiedades legacy con una API propietaria que nadie había tocado en cuatro años. La integración sola se extendió tres semanas. Costo final: £47,500. El cliente estuvo bien porque la señalamos en el momento en que encontramos la documentación de la API — pero la estimación inicial seguía siendo ficción, y yo asumo esa responsabilidad.
El Cono de Incertidumbre Es Real
El cono de incertidumbre, popularizado por Steve McConnell, describe cómo las estimaciones de proyectos se hacen más precisas conforme te acercas a la entrega. En la ideación, podrías estar equivocado por 4x en cualquier dirección. Después del diseño detallado, quizás 1.25x. La mayoría de los fundadores reciben cotizaciones en la etapa de ideación y las tratan como contratos firmados., popularised by Steve McConnell, describes how project estimates get more accurate as you get closer to delivery. At ideation, you might be off by 4x in either direction. After detailed design, maybe 1.25x. Most founders are getting quotes at the ideation stage and treating them like signed contracts.
La implicación práctica: cualquier cotización que recibas antes de que se escriban especificaciones detalladas debe tratarse como un rango, no como un número. Si una agencia te da una cifra única antes de haber visto tu modelo de datos, flujos de usuario, y dependencias de terceros — ese número es decorativo.range, not a number. If an agency gives you a single figure before they've seen your data model, user flows, and third-party dependencies — that number is decorative.
---
Los Cuatro Buckets Reales de Costo
Antes de que cualquier estimador pueda trabajar, necesitas dividir el proyecto en las categorías correctas. No "frontend, backend, QA" — esos son roles, no factores de costo. Los buckets reales:
1. Trabajo Greenfield vs. Integración
Greenfield — construir algo desde cero contra tu propia base de datos y lógica de negocio — es la mitad más barata y predecible de casi cualquier proyecto. Es el trabajo de integración lo que te mata. Cada API externa, sistema heredado, procesador de pagos o proveedor de autenticación de terceros agrega complejidad no lineal. Típicamente agrego un contingente de 30–40% a cualquier línea de alcance que toque sistemas externos.
2. Diseño UI/UX (No Omitas Esta Línea)
Muchos fundadores tratan el diseño como opcional o intentan incluirlo en la estimación de desarrollo. Error. Diseño hecho correctamente — wireframes, prototipos interactivos en Figma, una biblioteca de componentes probada — típicamente cuesta 15–25% del costo total del proyecto. Omítelo y pagarás el doble: una vez en retrabajos del desarrollador cuando los requisitos resulten ambiguos, y otra vez en investigación de usuarios después cuando el producto no convierta.Figma, a tested component library — typically runs 15–25% of total project cost. Skip it and you'll pay twice: once in developer rework when requirements turn out to be ambiguous, and again in user research later when the product doesn't convert.
3. Infraestructura y DevOps
Nadie lo cotiza correctamente. Ambientes de staging, pipelines de CI/CD (usamos GitHub Actions en casi todo ahora), containerización con Docker, hosting en la nube en AWS o GCP — estos son costos reales que no desaparecen porque nadie los itemizó. Para un SaaS de complejidad media, presupuesta un mínimo de £3,000–£6,000 para la configuración inicial de infraestructura, más costos mensuales continuos que típicamente corren £200–£800 dependiendo del uso.
4. Testing, QA y Gastos de Lanzamiento
Suites de pruebas automatizadas, pasadas manuales de QA, testing de rendimiento, revisión de seguridad para cualquier cosa que maneje pagos o datos personales — esto es típicamente 20% del tiempo total de desarrollo si se hace bien. La mayoría de las cotizaciones de agencias incluyen "testing" como una línea y significan "un dev hizo clic durante una tarde antes de la llamada de entrega".
---
Un Estimador Funcional: El Método de Módulos
Aquí está el marco real. Lo llamo el Método de Módulos porque te obliga a desglosar un proyecto en fragmentos discretos, estimables independientemente, en lugar de tratarlo como un monolito.
Paso 1: Lista cada feature como una user story. No "gestión de usuarios" — es demasiado vago. "Un usuario puede registrarse con correo y contraseña, verificar su correo, restablecer su contraseña y actualizar su foto de perfil." Cuatro stories. Cada una tiene un costo.Not "user management" — that's too vague. "A user can register with email and password, verify their email, reset their password, and update their profile photo." Four stories. Each one has a cost.
Paso 2: Califica cada story por complejidad. Yo uso tres niveles:I use three tiers:
- Simple (S): CRUD puro, sin dependencias externas, patrones de UI estándar. Piensa: una página de configuración, un formulario de actualización de perfil, una tabla de datos con ordenamiento.(S): Pure CRUD, no external dependencies, standard UI patterns. Think: a settings page, a profile update form, a data table with sorting.
- Medio (M): Algo de lógica de negocio, una integración externa, o UI no estándar. Piensa: una búsqueda filtrada con queries guardadas, un manejador de webhook, un flujo de suscripción con Stripe.(M): Some business logic, one external integration, or non-standard UI. Think: a filtered search with saved queries, a webhook handler, a Stripe subscription flow.
- Complejo (C): Múltiples integraciones, features en tiempo real, lógica algorítmica, o infraestructura pesada. Piensa: un sistema de chat en vivo, un motor de recomendaciones, un modelo de permisos multi-tenant.(C): Multiple integrations, real-time features, algorithmic logic, or heavy infrastructure. Think: a live chat system, a recommendation engine, a multi-tenant permission model.
Paso 3: Asigna rangos de horas, no estimaciones en puntos.
En 2026, trabajando con una agencia mid-tier del Reino Unido o un equipo nearshore sólido, aquí está lo que presupuestaría:
- Story simple: 4–8 horas
- Story medio: 12–24 horas
- Story complejo: 30–80 horas (sí, ese rango es amplio — lo complejo es genuinamente impredecible)
Paso 4: Aplica tu tarifa.
Tasas de mercado actuales que vale la pena conocer:
- Desarrollador senior con base en Londres (freelance): £90–£140/hr
- Agencia del Reino Unido (equipo completo, gestionado por proyecto): £80–£120/hr combinada
- Nearshore fuerte (Europa del Este, LatAm): £35–£65/hr
- Offshore (Asia del Sur, Filipinas): £15–£35/hr — y sí, puedes obtener trabajo excelente aquí, pero la sobrecarga de comunicación es real y necesita ser considerada en el precio
Paso 5: Suma los gastos generales explícitamente.
No los absorbs. Detállalos por línea:
- Gestión de proyecto: 10–15% de las horas de desarrollo
- Diseño (si no está ya alcanzado): 15–25% del total
- Configuración de DevOps/Infraestructura: £3,000–£8,000 fijos según la complejidad
- QA: 20% de las horas de desarrollo como mínimo
- Contingencia: 20% en trabajo greenfield, 35% en cualquier cosa con integración significativa
---
Un Ejemplo Real: Dashboard SaaS, Precios 2026
Déjame mostrarte algo concreto. Un fundador me contacta queriendo un dashboard de analítica B2B — un producto SaaS donde sus clientes inician sesión, ven sus datos de desempeño obtenidos de Google Analytics 4 y una base de datos de eventos personalizados, pueden exportar reportes y gestionar el acceso de su propio equipo.
Así es como lo dividiría:
- Sistema de autenticación (email + Google SSO, acceso basado en roles): 2 historias Medium = 48 hrs2 Medium stories = 48 hrs
- Integración GA4 + pipeline de datos: 1 historia Complex = 55 hrs1 Complex story = 55 hrs
- Schema de base de datos de eventos personalizados + API: 2 historias Medium = 40 hrs2 Medium stories = 40 hrs
- Interfaz de panel (gráficos con Chart.js o Recharts, responsive): 3 historias Medium = 65 hrs3 Medium stories = 65 hrs
- Exportar reportes a PDF/CSV: 1 historia Medium = 18 hrs1 Medium story = 18 hrs
- Gestión de equipo (invitar, eliminar, asignación de roles): 2 historias Simple + 1 historia Medium = 28 hrs2 Simple + 1 Medium stories = 28 hrs
- Facturación con Stripe (suscripciones, mejorar/reducir): 1 historia Complex = 45 hrs1 Complex story = 45 hrs
Total de desarrollo raw: ~299 horas
Aplicar una tarifa promedio de agencia UK de £95/hr: £28,405£28,405
Agregar:
- Diseño (20%): £5,681
- Configuración DevOps: £4,500
- QA (20% de horas de desarrollo, misma tarifa): £5,681
- PM (12%): £3,409
- Contingencia de integración (30% en trabajo de GA4 y Stripe): £3,000
Presupuesto total: ~£50,676
Es un número real para un producto real. No es sorprendente si entiendes qué incluye. Absolutamente sorprendente si esperabas £18,000 porque eso es lo que alguien le dijo a un fundador en tu red hace un año por "algo parecido".
---
Los Costos Ocultos que Nadie Menciona
Licencias y Servicios de Terceros
Mapbox para funciones de mapeo. Twilio para SMS. SendGrid para correo transaccional. Algolia si necesitas búsqueda de verdad. Estos son costos continuos que los fundadores rutinariamente omiten de su presupuesto de software completamente porque los piensan como "solo APIs". Un SaaS de escala media con 10,000 usuarios activos podría estar pagando £800–£2,000/mes en tarifas de servicios de terceros antes de que llegue una sola factura de servidor.
Seguridad y Cumplimiento Normativo
Si manejas datos personales en el Reino Unido, GDPR no es opcional. Si tocas pagos, el cumplimiento de PCI DSS agrega complejidad. Si estás en salud o finanzas, estás viendo costos de auditoría adicionales que pueden correr £5,000–£20,000 solo para trabajo de certificación inicial. He visto fundadores genuinamente sorprendidos por esto. Un cliente fintech nuestro en 2023 había presupuestado cero libras para trabajo de cumplimiento y después necesitó £14,000 antes de poder lanzarse.PCI DSS complianceadds overhead. If you're in health or finance, you're looking at additional audit costs that can run £5,000–£20,000 just for initial certification work. I've seen founders get genuinely blindsided by this. One fintech client of ours in 2023 had budgeted zero pounds for compliance work and then needed £14,000 of it before they could launch.
Entrega y Documentación
La buena documentación —docs de API, runbooks de deployment, guías de onboarding para desarrolladores futuros— cuesta tiempo real. Presupuesta 5–8% del total de horas del proyecto si alguna vez quieres poder mantener, extender o vender el producto.
---
Cómo Validar una Cotización que Recibiste
Tienes una propuesta enfrente. Así es como la auditas antes de firmar:
- Pide el desglose de features detrás del número. Si no pueden darte un desglose a nivel de historias, la cotización es una adivinanza.
- Verifica si DevOps, QA y PM son líneas separadas o están ocultos en una tarifa combinada. Lo oculto usualmente significa que está poco cocido.
- Pregunta cuál es la política de contingencia. ¿Cierran los sobrecostos? ¿Tiempo y materiales o precio fijo? Cada uno tiene implicaciones reales.
- Averigua qué supuestos han hecho sobre integraciones de terceros. Pregúntales directamente: "¿Leyeron la documentación de la API para [servicio específico] antes de cotizar?"
- Pregunta qué sucede si los requisitos cambian después del sprint 2. La respuesta te dice casi todo sobre cómo opera la agencia.
La metodología Shape Up de Basecamp tiene un encuadre genuinamente útil para esto: tiempo fijo, alcance variable. Vale la pena leerla antes de entrar en cualquier negociación con una agencia.has a genuinely useful framing for this: fixed time, variable scope. It's worth reading before you enter any agency negotiation.
---
Herramientas de IA en 2026: Qué cambian (y qué no)
Todos quieren saber si GitHub Copilot, Cursor, o la nueva ola de herramientas de codificación basadas en agentes (Devin, Replit Agent) han reducido materialmente los costos de software. ¿Honestamente? Sí, un poco. Pero menos de lo que sugiere el hype.
Mi experiencia aproximada: desarrolladores fuertes asistidos por IA trabajan alrededor de 20–30% más rápido en trabajo CRUD greenfield. Ese trozo del medio de características estándar — formularios, tablas, flujos de autenticación básica — sí sale más rápido. Pero el trabajo de integración compleja, las decisiones arquitectónicas, depuración de condiciones de carrera sutiles, y cualquier cosa que requiera pensamiento profundo del producto: la IA no ayuda ahí, y en algunos casos genera código que se ve plausible pero introduce nuevos problemas.
Aplicaría un descuento de eficiencia de 10–15% a historias simples y medianas en 2026 si el equipo está confirmado que usa herramientas de IA seriamente. No más que eso. Cualquiera que te cotice 50% más barato "porque usamos IA" o está ejecutando un tipo de proyecto muy diferente del que piensas, o te está diciendo algo demasiado bueno para ser verdad.
---
FAQ
¿Qué tan preciso puede ser realmente un estimado de software antes de que las especificaciones estén escritas?
No muy preciso. Espera una varianza de ±40–60% en la etapa de idea. Una vez que tienes flujos de usuario detallados, un modelo de datos, y una lista de todas las dependencias de terceros, puedes llegar a ±20%. Después de un sprint de descubrimiento con wireframes y arquitectura técnica: ±10–15%. Paga por un compromiso de descubrimiento adecuado antes de que te comprometas a un presupuesto de construcción completo — típicamente cuesta £2,000–£6,000 y es el mejor dinero que gastarás en el proyecto.
¿Debería optar por precio fijo o tiempo y materiales?
Precio fijo te da certeza presupuestaria pero traslada el riesgo a la agencia — lo que significa que inflarán la estimación y se protegerán con cláusulas de cambio de alcance. Tiempo y materiales es honesto pero requiere que gestiones activamente el alcance. Mi preferencia para la mayoría de fundadores: precio fijo por sprint (típicamente 2 semanas), con alcance definido al inicio de cada sprint. Obtienes predecibilidad sin el juego del inflado.
¿El desarrollo nearshore u offshore realmente es más barato una vez que factorizas la sobrecarga de gestión?
Frecuentemente, pero no siempre. La sobrecarga es real — más tiempo de PM, más comunicación asincrónica, ocasional rehacimiento por expectativas desalineadas. Para un proyecto bien definido con especificaciones sólidas, nearshore (Europa del Este particularmente) ofrece valor genuino. He dirigido proyectos exitosos a £40/hr combinado con equipos de Polonia y Ucrania. Para algo ambiguo y que se mueve rápido, lo mantendría más cerca de casa.
¿Cuál es una bandera roja en una propuesta de software?
Una cotización de una sola línea sin desglose. Una cronología que no incluya QA o despliegue. Sin mención de cómo se manejan las solicitudes de cambio. Y honestamente — cualquier agencia que no te haga preguntas difíciles sobre tu infraestructura existente antes de cotizar. Si no tienen curiosidad por tus limitaciones, no han pensado seriamente en tu proyecto.
¿Cómo presupuesto el mantenimiento posterior al lanzamiento?
Regla estándar: 15–20% del costo de construcción inicial por año para mantenimiento continuo, corrección de bugs y trabajo de características menores. Una construcción de £50,000 necesita un presupuesto de mantenimiento anual de £7,500–£10,000. Si alguien te dice que el software está "listo" al lanzamiento, busca otras personas de software.
---
¿El fundador de logística de noviembre? Volvió a su agencia, refactorizaron su proceso de trabajo, y el producto se lanzó en marzo. Está funcionando bien. Pero me dijo que deseaba que alguien le hubiera entregado un framework como este antes de firmar cualquier cosa. Así que. Aquí está.