Un presupuesto de software a medida debe permitir decidir qué se construye, cómo se comprueba y qué compromiso queda después del lanzamiento. Una lista de pantallas y una cifra final no bastan para comparar proveedores. Tampoco basta con pedir «un bot» o «conectar el CRM»: cada uno puede estar presupuestando un comportamiento distinto.
Yo empiezo por el proceso de negocio y separo definición, construcción, puesta en producción y mantenimiento. Esta guía te ayuda a preparar una solicitud y revisar propuestas de software o automatización sin asumir tarifas, plazos ni ahorros que todavía no se han validado.
Qué necesito antes de preparar un presupuesto
No necesitas escribir una especificación técnica completa. Necesito entender quién hace el trabajo, qué información utiliza y dónde se atasca. Estos son los datos que puedes reunir en un brief:
- Problema: qué tarea falla o consume trabajo manual, quién la realiza y qué consecuencia tiene.
- Primer recorrido: qué inicia el proceso, qué debe producir y quién acepta el resultado.
- Sistemas y datos: herramientas actuales, accesos disponibles y una muestra anonimizada de entradas y salidas.
- Volumen y excepciones: carga habitual, picos conocidos y casos que hoy requieren una decisión humana. Si no se mide, indícalo como pendiente.
- Límites: presupuesto disponible si existe, fecha y motivo, requisitos de acceso y lo que puede esperar.
- Responsables: quién resuelve dudas de negocio, facilita acceso y mantiene el sistema después.
Con ese contexto puedo decidir si conviene adaptar una herramienta existente, acotar una integración o construir producto. Es el punto de partida de cómo planteo un proyecto antes de programar.
Qué debe incluir un presupuesto de software a medida
Pide que las propuestas respondan a la misma primera versión. Marca cada partida como incluida, opcional, excluida o pendiente de investigar. Una partida pendiente necesita una decisión antes de poder tratar el importe como cerrado.
| Partida | Qué debe quedar escrito | Cómo comprobarlo |
|---|---|---|
| Alcance | Usuarios, recorrido completo, datos y exclusiones. | Demostración del flujo acordado, incluidos permisos y errores. |
| Integraciones y migración | Sistemas, dirección de los datos, limpieza y tratamiento de duplicados. | Muestra de migración y pruebas con fallos de conexión. |
| Entrega | Hitos, entorno de pruebas, responsable de validar y condiciones de aprobación. | Evidencia de cada criterio antes de aceptar el hito. |
| Producción | Despliegue, configuración, registros, alertas y recuperación necesaria. | Recorrido de operación y procedimiento ante un fallo. |
| Operación | Hosting, licencias, consumos externos y quién los paga. | Supuestos de uso y costes separados de la construcción. |
| Soporte y salida | Cobertura, correcciones, mejoras, acceso al código y documentación. | Inventario de cuentas y traspaso que pueda utilizar el equipo. |
También deben quedar claros los hitos de pago y cómo se aprueban los cambios de alcance. Si una propuesta incluye migrar datos y otra solo entrega una aplicación vacía, sus totales no describen la misma compra.
Ejemplo de alcance y pruebas de aceptación
Ejemplo hipotético: una empresa quiere pasar solicitudes desde un formulario a su CRM. La primera versión incluye un formulario, un CRM, campos acordados y una cola de incidencias para operaciones. Quedan fuera la sincronización inversa, el histórico y la clasificación con IA.
Antes de aceptar esa entrega, acordaría pruebas como estas:
- Una solicitud válida crea el registro con los campos y el responsable acordados.
- Reenviar la misma solicitud no crea otra oportunidad; se define qué identificador permite reconocerla.
- Si el CRM no responde, la solicitud queda pendiente y el operador puede ver qué ocurrió.
- Cuando vuelve la conexión, el caso pendiente puede recuperarse sin perder datos ni duplicar la operación.
- Una entrada incompleta se deriva a revisión con un motivo visible.
- Una persona sin permisos no puede consultar los datos de la solicitud.
El volumen, el tiempo aceptable de procesamiento y los intentos de recuperación se acuerdan con datos del proceso. No son garantías universales. Para profundizar en esas dependencias, consulta el recorrido de datos hasta un CRM.
Precio cerrado, descubrimiento o trabajo por fases
Un precio cerrado encaja cuando entradas, accesos, comportamiento y aceptación están definidos. Si una API no se ha probado o nadie conoce la calidad del histórico, prefiero acotar primero una fase de descubrimiento. Su entrega debe resolver la incertidumbre: una prueba de conexión, una muestra de datos y un alcance revisado.
En un trabajo por fases, cada hito necesita resultado, límite de inversión acordado y punto de revisión. Si se trabaja por tiempo, hay que acordar cómo se informa del consumo y quién autoriza continuar. Ningún modelo elimina los cambios; debe hacer visible su efecto en coste y calendario.
La guía de estimación de desarrollo software explica cómo dividir esfuerzo e incertidumbre. Aquí la decisión es qué entrega estás aprobando y bajo qué supuestos.
Qué separo del coste inicial
Distingo construir el sistema de operarlo. Infraestructura, servicios externos, consumo de APIs, soporte e incorporación de nuevas funciones pueden tener condiciones distintas. Una corrección sobre un criterio pactado y una funcionalidad nueva también deben distinguirse en la propuesta.
En automatización reviso qué sucede si cambia una fuente o caduca un acceso, quién recibe la alerta y cómo retoma el trabajo. El caso Adslyfy muestra registros de ejecución, intentos y capturas para investigar fallos. Es evidencia de esas piezas operativas, no una referencia de precio o de ahorro.
Cómo decidir entre propuestas
Mi criterio es comprobar primero que las propuestas cubren el mismo recorrido y después revisar los riesgos abiertos. Pide aclaraciones sobre una entrega que no puedas verificar, un coste recurrente sin responsable o una dependencia sin acceso confirmado. Recortar alcance explícitamente puede ser una buena decisión; dejarlo ambiguo dificulta saber qué estás comprando.
Si necesitas una revisión técnica de las opciones antes de elegir proveedor, ese trabajo encaja con dirección técnica externa. Si el alcance ya está claro, podemos pasar a la ejecución.
Prepara el siguiente paso
Trabajo en software a medida y SaaS y en automatización de procesos. Para valorar tu proyecto, envíame el proceso actual, los sistemas implicados y el primer resultado que necesitas. Si ya tienes propuestas, resume sus diferencias sin compartir credenciales ni datos de clientes.
Podemos empezar por revisar el alcance de tu proyecto y decidir qué información falta para preparar una propuesta útil.