Presupuesta un proyecto de software por el tipo de build y el alcance, no por un número a ojo. Conmigo, un sitio web cuesta $1,800, precio fijo (la tarifa 2026), y lo que va más allá de un sitio web — una app o un MVP SaaS — se cotiza desde tu roadmap. 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 números en realidad?
Cómo se ve el camino completo conmigo en 2026:
- El Diagnóstico de Crecimiento de $399: acreditado íntegro al build; su roadmap escrito fija el alcance.
- Sitio web: $1,800, precio fijo (la tarifa 2026).
- MVP SaaS: se cotiza desde tu roadmap.
- App web o herramienta interna: se cotiza desde tu roadmap, según roles e integraciones.
- Después del lanzamiento: un plan Care o Growth a 12 meses; en software, la tarifa del plan se cotiza con el proyecto.
La única fecha que doy por adelantado es la del roadmap escrito, el entregable del diagnóstico. Llega en 5 días hábiles, y la fecha de inicio se acuerda en la llamada que le sigue. En software, el alcance decide el número. 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. Esa sola disciplina — nombrar lo que no vas a construir todavía — suele ahorrar más que cualquier negociación sobre la tarifa por hora, porque el alcance mueve el precio mucho más que la tarifa.
¿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 a partir del roadmap del diagnóstico 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. Tus clientes y tus datos son siempre tuyos, y al final del plazo, con todo pagado, te entrego el código fuente si lo pides. 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 (una cuota anual pequeña), 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. Conmigo, ese trabajo continuo va en el plan Care o Growth.
¿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.
