Qué debe incluir un presupuesto de software a medida

El alcance debe explicar resultados, no solo pantallas

Una lista de pantallas parece concreta, pero dice poco sobre la complejidad real. La misma pantalla de pedidos puede limitarse a guardar un formulario o coordinar stock, permisos, facturación, transporte y notificaciones.

El presupuesto debería describir los flujos que estarán operativos al terminar: quién inicia cada proceso, qué reglas intervienen y qué resultado puede obtener el usuario. Así es posible comprobar si dos propuestas están presupuestando realmente lo mismo.

• Perfiles de usuario y permisos principales.
• Procesos incluidos y resultado esperado de cada uno.
• Integraciones con sistemas o proveedores externos.
• Datos que deben importarse o migrarse.
• Entornos y dispositivos que debe soportar la solución.
• Requisitos relevantes de seguridad y disponibilidad.

Entregables que conviene dejar por escrito

Precio cerrado, bolsa de horas o trabajo por fases

Un precio cerrado funciona cuando el alcance puede definirse con precisión y existe poca incertidumbre. Ofrece previsibilidad, pero cualquier supuesto incorrecto termina convertido en una discusión sobre cambios.

El trabajo por tiempo permite aprender y repriorizar, aunque necesita transparencia: equipo, dedicación, ritmo de entrega y control presupuestario. Para proyectos con incertidumbre suele funcionar mejor una primera fase cerrada de discovery y un desarrollo posterior dividido en hitos.

No existe un modelo de precio universalmente mejor. El modelo correcto es el que hace visible la incertidumbre en lugar de esconderla dentro de una cifra.

Las exclusiones protegen a ambas partes

Que una propuesta indique qué no incluye no es una señal negativa. Permite detectar dependencias antes de firmar y evita interpretar como incluido cualquier elemento que apareció en una conversación.

• Licencias, servicios externos y consumo de APIs.
• Carga manual o limpieza de datos no especificada.
• Textos, traducciones, fotografía y otros contenidos.
• Dispositivos, cuentas de tiendas o certificados de terceros.
• Soporte fuera de horario y acuerdos de disponibilidad.
• Nuevas funcionalidades posteriores a la aceptación.

Código, accesos, garantía y mantenimiento

El presupuesto o contrato debe identificar quién será propietario del código desarrollado, dónde se alojará el repositorio y qué accesos recibirá el cliente. También conviene separar la corrección de defectos de la evolución del producto.

La garantía cubre normalmente comportamientos que no cumplen lo acordado. No equivale a mantenimiento indefinido ni a incorporar nuevas necesidades. Después del lanzamiento deben quedar visibles el coste de infraestructura, soporte y futuras iteraciones.

Cómo comparar dos propuestas

• Comprueba que ambas incluyen los mismos procesos e integraciones.
• Revisa qué supuestos podrían modificar el precio.
• Pregunta quién participará realmente en el proyecto.
• Valora la frecuencia de demostraciones y validaciones.
• Compara propiedad, documentación y dependencia futura.
• Calcula el coste del primer año completo, no solo del desarrollo.