Presupuesta un proyecto de software por el tipo de build y el alcance, no por un número a ojo. En 2026, un sitio enfocado ronda los $1.5K, un sitio de varias páginas suma de 4 a 8 semanas de trabajo encima, y un MVP SaaS arranca en $8K. El número se mueve con la complejidad — roles, integraciones y qué tan claro está "terminado". Fija el alcance primero y el presupuesto deja de ser una adivinanza. Sáltate ese paso y no estás presupuestando; estás esperando que salga bien.
¿Cómo son los rangos en realidad?
Rangos honestos de 2026, de builds reales:
- Sitio enfocado o landing: unos $1.5K, 2 a 4 semanas.
- Sitio de marketing de varias páginas: más, normalmente 4 a 8 semanas.
- MVP SaaS: $8K en adelante, 6 a 10 semanas.
- App web o herramienta interna: típicamente $10K–$30K según roles e integraciones.
Son puntos de partida, no cotizaciones — el alcance decide dónde caes dentro o por encima de cada banda. Una buena regla: si todavía no puedes decir cómo se ve "terminado", no estás listo para poner un número — acótalo primero y después ponle precio.
¿Qué mueve más el número?
Tres cosas, en orden: alcance (número de páginas o funciones), complejidad (diseño a medida, roles de usuario, lógica de cobros, integraciones) y criterios de aceptación poco claros. Las dos primeras se planean; la tercera es la que dobla presupuestos en silencio cuando "terminado" no se define al inicio. Las integraciones merecen cuidado especial — cada sistema externo al que te conectas (pagos, un CRM, una API de terceros) suma trabajo que solo controlas en parte, porque sus rarezas se vuelven tu problema. La línea más barata siempre es la función que acuerdas no construir todavía.
¿Precio fijo o por hora — cuál protege tu presupuesto?
Para un build definido, el precio fijo te protege: apruebas un número antes de empezar y el riesgo de una mala estimación es mío, no tuyo. Por hora encaja en trabajo de verdad abierto — descubrimiento, iteración continua — donde fingir un precio fijo solo significa inflarlo. El peligro con por hora es un medidor abierto sin techo; el peligro con precio fijo es un alcance vago que vuelve cada cambio un "extra". Cualquiera es justo con un alcance escrito y un tope; ninguno lo es sin ello. Cubro el tradeoff en precio fijo vs por hora.
¿Cómo cotizo para que no se desvíe?
Cierro un alcance fijo antes del primer sprint y cotizo contra él, así el precio no se mueve a mitad del proyecto. Si el alcance cambia, es una conversación deliberada, no una factura sorpresa. Además eres dueño del código y del despliegue — sin lock-in, sin cuotas mensuales que te amarren. Ese enfoque de alcance fijo es la diferencia entre un proyecto que cae en presupuesto y uno que se desborda: cada cambio es una decisión que tomas con el precio enfrente, no una línea que descubres al final.
¿Qué presupuestar más allá del build?
Planea lo que viene tras el lanzamiento: un dominio (~$10–15 al año), hosting (a menudo modesto o incluso en capa gratis en un stack moderno como Vercel para empezar) y — lo más importante — tiempo o presupuesto para iterar cuando llegue el uso real. El build es el inicio del trabajo, no el final. Los equipos que sacan más de un proyecto guardan algo de margen para la primera ronda de mejoras, porque la mejor información sobre qué construir después solo aparece cuando gente real usa la v1. Presupuesta la primera iteración, no solo el lanzamiento. Si el sitio es central para el negocio, deja también un poco para mantenimiento ligero — actualizaciones, backups y seguridad — que en un stack moderno es modesto, pero no es cero.
¿Cómo evitas que un presupuesto estalle?
Tres hábitos: define "terminado" por escrito antes de que alguien codifique, pon las ideas nuevas en una lista de v2 en vez de en el build actual, y prefiere un alcance fijo para que los cambios sean deliberados. La mayoría de los presupuestos reventados no vienen de malas estimaciones — vienen de un alcance que creció en silencio porque nadie escribió dónde paraba. Un límite claro el día cero es el seguro más barato de todo el proyecto. Si puedes nombrar el único resultado que la v1 debe probar, puedes sostener la línea en todo lo que no sea eso — que es justo lo que recorre cómo acotar un MVP.
Guías de estrategia relacionadas
Combínalo con qué construir primero y cómo acotar un MVP. Para detalles por línea, mira mis servicios.
¿Quieres un número real para tu proyecto? Cuéntame el alcance — te doy un precio fijo.
