Tarifas: cada proyecto se presupuesta

Por qué un presupuesto y no una lista de precios

En resumen: Dos proyectos descritos con la misma frase — «una web corporativa», «un agente conversacional» — pueden exigir trabajos incomparables. La frase no dice el alcance; el precio sigue al alcance.

Una lista de precios supone productos comparables. Un software vendido por licencia puede tenerla: el producto es idéntico para todos. Un trabajo a medida no, porque lo que se entrega cambia cada vez. «Una web corporativa» puede designar una página única alimentada por un texto ya escrito, o un conjunto multilingüe conectado a un sistema de gestión existente, con reglas de acceso y migración de contenidos. El mismo rótulo cubre dos cargas de trabajo que no tienen nada que ver.

Publicar un precio de partida esquiva el problema en lugar de resolverlo. La cifra atrae, luego el alcance real la contradice, y la conversación empieza con una corrección: mala manera de empezar. La alternativa honesta consiste en decir qué hace variar el coste, decirlo antes, y fijar el importe una vez escrito el alcance.

Un presupuesto no es solo un precio. Es el primer documento donde el alcance queda escrito con claridad: qué está incluido, qué no, qué aporta el cliente y qué queda por producir. Esa parte es la que evita los desacuerdos posteriores, mucho más que el importe.

Qué hace variar el coste de un proyecto

En resumen: Cinco factores explican la mayor parte de las diferencias: el alcance funcional, el sistema existente que hay que retomar, el contenido y sus idiomas, las integraciones de terceros y el nivel de exigencia.

El alcance funcional es el factor más visible. Una página que presenta una oferta con un formulario de contacto no es el mismo trabajo que un espacio donde los usuarios se identifican, suben documentos y disparan procesos. Cada función trae su interfaz, sus casos de error, sus reglas de acceso y sus pruebas: la función en sí suele ser la parte más pequeña.

El sistema existente pesa igual, y se subestima más a menudo. Partir de cero a veces sale más barato que retomar un sistema en marcha cuyos datos hay que migrar, cuyas direcciones hay que conservar, cuyos usuarios tienen costumbres y que debe seguir funcionando durante el cambio. Una migración de datos mal documentada puede representar una parte importante del esfuerzo sin producir nada visible en pantalla.

El contenido determina una parte del coste que muchos descubren sobre la marcha. ¿Quién escribe los textos? ¿Están listos? ¿Cuántos idiomas, y quién valida cada uno? Una traducción no es una conversión mecánica: exige la revisión de alguien que hable el idioma y conozca el tema. Un proyecto puede estar técnicamente terminado y quedarse parado por falta de contenido.

Las integraciones de terceros añaden una dependencia de algo que no se controla: un sistema de pago, una aplicación de gestión, un servicio de envío, una fuente de datos. Cada una trae su autenticación, sus límites de uso, sus caídas posibles y una documentación más o menos fiel. El coste de una integración se mide menos por conectarla que por lo que obliga a prever cuando no responde.

El nivel de exigencia, por último, se elige y se paga. Accesibilidad verificada, rendimiento medido, seguridad revisada, cobertura de pruebas, documentación de explotación: son trabajos reales, no casillas. Pueden reducirse a conciencia; lo caro es descubrirlos después de la publicación.

Precio cerrado, por tiempo, o cuota: qué implica cada modelo

En resumen: Existen tres modelos de facturación, y la elección va menos de precio que de quién asume el riesgo. El presupuesto indica cuál se aplica y a qué.

El precio cerrado fija un importe para un alcance descrito. Traslada el riesgo de estimación al proveedor, lo que tranquiliza, con una condición: el alcance debe ser lo bastante preciso como para poder sostenerse. Su contrapartida es la rigidez. Todo lo que no está descrito queda fuera, y cada cambio pasa por una adenda. Conviene, por tanto, a lo estable y bien entendido, rara vez a una exploración.

La facturación por tiempo conviene a lo contrario: un alcance que va a evolucionar porque se aprende avanzando. Traslada el riesgo al cliente y solo es aceptable con una visibilidad real: qué se ha hecho, qué está en curso, qué se ha decidido. Sin ese seguimiento se convierte en un gasto sin timón.

La cuota cubre lo que no se detiene: mantenimiento, actualización de dependencias, vigilancia, correcciones, mejoras regulares. Corresponde a una realidad que el modo proyecto oculta: un sitio no es un objeto entregado y luego terminado. El punto que aclarar en una cuota es siempre el mismo: qué incluye, qué excluye y qué ocurre cuando una petición desborda su marco.

Estos modelos se combinan a menudo en un mismo proyecto: precio cerrado en la parte estable, tiempo en lo que queda por explorar, cuota una vez publicado. Lo que cuenta no es el modelo elegido, sino que esté nombrado y que sus límites estén escritos.

Qué reunir para obtener un presupuesto utilizable

En resumen: Un presupuesto vale lo que valió la descripción que lo precedió. Cuatro elementos bastan para pasar de una estimación vaga a una valoración seria.

El primero es el objetivo, formulado como resultado y no como solución. «Queremos una web» describe un medio. «Queremos que las peticiones de cita lleguen sin llamada telefónica» describe un resultado, y deja abierta la cuestión de si una web es la mejor respuesta. Un objetivo expresado como resultado permite además comprobar después si se ha alcanzado.

El segundo es lo existente: qué hay ya, qué debe conservarse, qué puede abandonarse. Direcciones actuales, cuentas, herramientas de uso diario, datos que migrar. Es la parte que más se omite en las peticiones de presupuesto, y la que explica más diferencias entre una estimación y un coste final.

El tercero es la restricción, sea cual sea: un presupuesto disponible, una fecha impuesta por un acontecimiento externo, una obligación normativa, una herramienta impuesta. Indicar el importe disponible no debilita su posición: permite ajustar el alcance en vez de recibir una propuesta fuera de lugar.

El cuarto es la decisión: quién valida y sobre qué. Un proyecto sin responsable identificado avanza hasta el primer arbitraje y se detiene. Nombrar a esa persona en el momento del presupuesto es el gesto más barato y el más olvidado.

Cómo comparar dos presupuestos

En resumen: Comparar importes antes que alcances no tiene sentido. El presupuesto más barato suele ser el que menos describe, que no es lo mismo que el que menos costará.

Empiece por poner los alcances uno al lado del otro, no los totales. Una diferencia de precio es casi siempre una diferencia de contenido: uno prevé la migración de datos, el otro no; uno incluye pruebas y aceptación, el otro las deja al cliente; uno valora tres idiomas, el otro uno. Mientras los alcances difieran, los importes no son comparables.

Mire después lo que se excluye explícitamente. Un presupuesto serio contiene una lista de exclusiones; su ausencia no indica que todo esté incluido, sino que la cuestión no se ha zanjado. Las exclusiones más frecuentes afectan al contenido, las traducciones, el alojamiento, las licencias de terceros y la formación.

Compruebe por último las cláusulas que no tienen precio pero sí coste: de quién es el código producido y las cuentas creadas, dónde se alojan los datos, qué se entrega al final y qué ocurre si la colaboración se detiene. Estos puntos solo se negocian bien antes de la firma. Después, se sufren.

Lo que el precio inicial no cubre

En resumen: La publicación no es el final del gasto. Alojamiento, nombres de dominio, dependencias de software y contenido siguen existiendo después de la entrega.

Un sitio publicado consume recursos: alojamiento, nombre de dominio, certificados, a veces servicios de terceros facturados por uso. Suelen ser partidas modestas frente al proyecto, pero son recurrentes, y una renovación olvidada deja un sitio fuera de línea con la misma seguridad que una avería.

Las dependencias de software envejecen. Las bibliotecas usadas publican correcciones, también de seguridad, y un proyecto sin actualizar se vuelve progresivamente difícil de retomar: cuanto más se acumula la distancia, más cuesta la puesta al día. Es el gasto más fácil de aplazar y el más caro de aplazar mucho tiempo.

El contenido, por último, envejece más deprisa que el código. Una oferta cambia, un servicio desaparece, una página se queda. La pregunta que hacer al presupuestar no es solo «¿quién lo construye?» sino «¿quién lo actualiza, y cómo?», porque un sitio que nadie puede modificar sin ayuda técnica acaba por no modificarse nunca.