Cómo presupuestar un proyecto web técnico siendo agencia: qué definir antes de presentar la propuesta

La agencia tiene un cliente interesado, un brief razonable, el diseño bastante avanzado y una fecha de lanzamiento sobre la mesa. Parece el momento de enviar la propuesta. Sin embargo, todavía nadie sabe qué ocurre exactamente al enviar el formulario, dónde se guardan los datos, quién dará de alta a los usuarios o cómo llegará el stock desde el sistema del cliente.

Es una situación habitual. También es una de las formas más arriesgadas de abordar un proyecto técnico: vender primero y descubrir el alcance después. Cuando las preguntas aparecen durante el desarrollo, la agencia ya ha comprometido precio, plazo y expectativas frente a su cliente.

Este artículo no trata sobre calcular una tarifa por hora ni sobre decidir si la agencia necesita apoyo externo. Esa decisión previa se aborda en la guía sobre cuándo una agencia necesita un partner técnico web. Aquí partimos de que la oportunidad ya existe y hay que convertirla en una propuesta defendible.

La agencia no necesita resolver toda la arquitectura antes de presupuestar. Sí necesita distinguir qué está definido, qué está suponiendo y qué puede cambiar de forma relevante el trabajo.

1. Un diseño todavía no es un alcance técnico

El diseño explica cómo debería verse y sentirse la experiencia. El alcance técnico explica qué debe ocurrir para que esa experiencia funcione. Son dos definiciones relacionadas, pero no equivalentes.

Una pantalla puede estar visualmente cerrada y seguir dejando abiertas preguntas importantes:

• ¿Qué ocurre cuando una persona envía el formulario?
• ¿Dónde se guarda la información y quién recibe el aviso?
• ¿Quién crea, bloquea o recupera las cuentas de usuario?
• ¿El stock se edita en la web o llega desde otro sistema?
• ¿Qué estados atraviesa un pedido después del pago?
• ¿Quién prepara, importa y comprueba el contenido inicial?

Incluso una interacción aparentemente sencilla puede esconder decisiones. Un botón que dice «solicitar presupuesto» puede abrir un formulario, iniciar un flujo con varios pasos, crear una oportunidad en el CRM, adjuntar archivos y avisar a un equipo distinto según el servicio seleccionado.

Por eso, antes de dar precio hay que convertir la idea y el diseño en decisiones suficientemente concretas. No hace falta escribir una especificación enorme. Hace falta poder explicar el comportamiento esperado y señalar con honestidad lo que todavía no se conoce.

2. Separar lo confirmado de lo supuesto

Esta separación es una de las herramientas más útiles para presupuestar con criterio. Una frase del cliente puede contener una necesidad confirmada y, al mismo tiempo, varias incógnitas que cambian el esfuerzo.

Por ejemplo:

• Requisito confirmado: el cliente necesita conectar la web con su CRM.
• Suposición: el CRM dispone de una API adecuada y accesible con el plan contratado.
• Decisión pendiente: todavía no se ha acordado si se enviarán solo contactos o también oportunidades y actividades.
• Dependencia: el departamento de sistemas debe facilitar documentación, credenciales y un entorno de prueba.
• Elemento opcional: sincronizar hacia la web los cambios realizados posteriormente en el CRM.

Si todo esto se resume como «integración con CRM incluida», la propuesta trata incógnitas como si fueran certezas. Es más útil mantener un registro breve con cinco estados: confirmado, supuesto, pendiente, dependencia y opcional.

Las suposiciones no son un problema cuando están escritas. Permiten presupuestar sobre una base concreta y revisar el impacto si después resultan falsas. El riesgo aparece cuando la agencia, el cliente y el equipo técnico están imaginando versiones distintas del mismo requisito sin saberlo.

3. Definir qué necesita poder hacer el usuario

Una lista de páginas ayuda a ordenar el diseño, pero dice poco sobre el esfuerzo de desarrollo. «Home, nosotros, contacto y productos» no aclara si el proyecto es una web informativa o una herramienta que participa en la operativa del cliente.

Conviene describir acciones. Por ejemplo:

• Registrarse, iniciar sesión o recuperar el acceso.
• Solicitar un presupuesto y aportar documentación.
• Comprar, pagar y consultar el estado de un pedido.
• Subir archivos y sustituirlos más adelante.
• Gestionar contenido desde un panel.
• Aprobar o rechazar solicitudes.
• Recibir avisos según condiciones concretas.
• Sincronizar información con otros sistemas.
• Acceder a áreas privadas según el tipo de usuario.

Para cada acción principal, la agencia debería poder responder quién la realiza, qué información necesita, qué resultado espera y qué ocurre después. También conviene identificar variantes: no es lo mismo enviar una solicitud que enviarla, validarla, asignarla a una delegación y permitir que el cliente consulte su estado.

En proyectos técnicos, la funcionalidad suele afectar más al presupuesto que el número de páginas. Diez páginas informativas pueden ser más previsibles que una única pantalla con permisos, reglas y datos externos.

4. Aclarar qué será editable

«El cliente quiere poder editar la web» sigue siendo demasiado amplio. Hay que concretar si podrá gestionar páginas, productos, servicios, miembros del equipo, testimonios, descargas, preguntas frecuentes u otros registros propios del negocio.

También hay que saber qué significa editar en cada caso:

• Cambiar textos e imágenes dentro de una estructura fija.
• Crear nuevos elementos siguiendo una plantilla.
• Reordenar secciones o registros.
• Relacionar contenidos entre sí.
• Publicar, ocultar o programar cambios.
• Gestionar filtros, categorías o estados.

Estas decisiones afectan al panel de administración, al modelo de datos, a las plantillas y a las pruebas. Un catálogo de servicios con campos definidos y relaciones no tiene el mismo alcance que varias páginas libres, aunque visualmente se parezcan.

Cuando la edición, los datos y los flujos son parte central del encargo, puede ser útil valorar un enfoque de desarrollo web a medida en lugar de forzar la solución alrededor de páginas independientes. La decisión técnica puede esperar; lo que no debería esperar es el inventario de información que el cliente necesita gestionar.

5. Identificar las reglas de negocio antes del desarrollo

El diseño enseña estados visibles, pero las reglas explican por qué se llega a cada uno. Son frases del tipo «si ocurre esto, entonces debe pasar aquello» y suelen aparecer durante las conversaciones comerciales como pequeños matices.

Algunos ejemplos:

• Los precios cambian según el tipo de cliente.
• Ciertos documentos solo pueden verlos determinados roles.
• El envío tiene condiciones especiales para algunas zonas o productos.
• Una solicitud necesita aprobación antes de avanzar.
• Cada formulario debe llegar al equipo correspondiente según provincia o servicio.
• Las reservas no pueden hacerse con menos de 48 horas de antelación.
• La disponibilidad depende del almacén y del canal de venta.
• El equipo trabaja con estados internos que el usuario no debe ver.

Una regla aparentemente pequeña puede cambiar bastante el alcance si afecta a varios flujos del proyecto. «Los clientes profesionales tienen condiciones distintas», por ejemplo, puede afectar al registro, los permisos, el catálogo, los precios, el pago y los correos.

No hace falta diseñar aquí la arquitectura. Basta con documentar las reglas que el negocio considera imprescindibles, sus excepciones conocidas y quién puede validarlas.

6. Las integraciones merecen preguntas propias

«La web tiene que conectarse con nuestro ERP» no contiene información suficiente para presupuestar una integración de forma fiable. Puede significar consultar stock una vez al día o coordinar en tiempo real productos, tarifas, clientes, pedidos, devoluciones y estados.

Antes de incluir la conexión en una propuesta, conviene aclarar:

• ¿Cuál es el sistema exacto y qué versión o plan utiliza?
• ¿Qué datos deben intercambiarse?
• ¿En qué dirección viaja cada dato?
• ¿La actualización debe ser inmediata, periódica o manual?
• ¿Qué sistema es responsable de cada dato?
• ¿Existe una API que cubra esas operaciones?
• ¿Hay documentación, credenciales y entorno de pruebas?
• ¿Quién responde por parte del proveedor del ERP o CRM?
• ¿Qué debe ocurrir si la conexión falla?
• ¿Cómo se detectarán duplicados, datos incompletos o desajustes?

Decir que «hay una integración» no define el trabajo. La planificación de integraciones técnicas necesita concretar sistemas, información, dirección, frecuencia y tratamiento del fallo. Si el sistema no ofrece la capacidad necesaria, quizá no baste con conectarlo y haya que estudiar una capa de APIs o servicios web.

Cuando aún no se dispone de documentación o acceso, esa falta de información debe aparecer como dependencia o como investigación pendiente, no ocultarse dentro de una cifra cerrada.

7. Asignar contenido, datos y materiales

Muchos desvíos no nacen del código, sino de tareas que nadie incluyó porque parecían responsabilidad de otra parte. La propuesta debería indicar quién prepara, entrega, revisa e incorpora:

• Textos y llamadas a la acción.
• Traducciones.
• Imágenes, vídeos, iconos y documentos.
• Productos, precios y datos de catálogo.
• Textos legales y consentimientos.
• Redirecciones desde URLs antiguas.
• Metadatos SEO facilitados para cada página.
• Ficheros para importaciones o migraciones.
• Credenciales y accesos a servicios externos.

«El cliente proporciona el contenido» también necesita límites: en qué formato, para qué fecha, con qué estructura y quién lo carga. Recibir una hoja con datos inconsistentes no equivale a recibir un catálogo preparado para importar. Ordenarlo, limpiarlo y completar campos puede convertirse en un trabajo relevante.

La finalidad no es convertir la propuesta en un artículo sobre contenidos o SEO. Es evitar que la carga, la corrección o la transformación de materiales aparezcan como alcance oculto cuando el proyecto ya está en marcha.

8. Distinguir entre un proyecto nuevo y uno heredado

Si ya existe una web, una tienda o una aplicación, el punto de partida no está en blanco. Antes de estimar una intervención significativa hay que entender qué se conserva, qué se sustituye y qué limitaciones introduce lo actual.

La revisión inicial debería identificar:

• CMS, framework y versiones utilizadas.
• Hosting, despliegue y accesos disponibles.
• Código personalizado y su estado.
• Plugins, módulos y licencias relevantes.
• Integraciones activas, aunque no estén documentadas.
• Contenido, usuarios, pedidos y otros datos que deben preservarse.
• URLs, analítica o configuraciones que no pueden perderse.
• Problemas conocidos y deuda técnica.
• Disponibilidad del proveedor anterior o del equipo de sistemas.

No conviene presupuestar un proyecto heredado importante como si fuera una implementación nueva sin revisar antes lo que ya existe. A veces reaprovechar reduce trabajo; otras veces condiciona la solución y añade migración, compatibilidad o estabilización.

Si todavía no hay accesos suficientes, la propuesta debe recoger esa limitación y evitar prometer conclusiones que dependen de una revisión pendiente.

9. Definir los límites de responsabilidad

Cada parte importante del proyecto necesita un responsable. Si la agencia cree que el cliente prepara los datos, el cliente cree que los cargará desarrollo y desarrollo espera recibirlos listos, el problema no es técnico: falta una decisión de proyecto.

Un reparto orientativo podría ser este:

No es un modelo universal. Una agencia puede preparar contenido, el cliente puede contar con su propio equipo técnico y el partner puede participar directamente en reuniones. Lo importante es que cada responsabilidad relevante tenga un propietario y que la propuesta refleje el reparto real.

También conviene definir quién consolida el feedback y quién tiene autoridad para aprobar. Recibir instrucciones contradictorias de varias personas añade trabajo y hace imposible saber cuándo una entrega está validada.

10. Separar trabajo propio de dependencias externas

El equipo puede controlar cuánto tarda en implementar una función, pero no cuándo responderá el proveedor del ERP, cuándo entregará el cliente sus traducciones o si el departamento de sistemas autorizará un acceso.

Entre las dependencias frecuentes están:

• Proveedor de hosting.
• Fabricante o consultora del ERP.
• Pasarela de pago.
• Proveedor de API.
• Acceso al dominio y a los DNS.
• Diseñador externo.
• Equipo de traducción.
• Departamento de sistemas del cliente.

La estimación debería distinguir trabajo controlado por el equipo de tiempo o resultados que dependen de terceros. Esto no significa dejar el calendario abierto. Significa indicar qué hitos necesitan información, validación o acceso externo y qué consecuencias tiene recibirlos tarde.

Una fecha de lanzamiento puede mantenerse como objetivo, pero debe apoyarse en condiciones visibles. Si la integración no puede probarse hasta que un proveedor facilite el entorno, esa dependencia no debería convertirse silenciosamente en responsabilidad de la agencia.

11. Explicar qué queda fuera

Las exclusiones no son burocracia defensiva. Ayudan a que agencia y cliente entiendan qué compra exactamente la propuesta y evitan comparar ofertas que incluyen trabajos distintos.

Según el proyecto, puede ser razonable excluir o valorar aparte:

• Creación o revisión de contenidos.
• Traducciones.
• Estrategia y ejecución SEO.
• Limpieza manual de datos.
• Licencias y costes de terceros.
• Revisión legal o preparación de textos legales.
• Funcionalidades no descritas en el alcance.
• Cambios de sistemas externos después de la validación.
• Soporte o trabajo evolutivo posterior al lanzamiento.

Una exclusión útil es concreta y comprensible. «Todo lo no indicado» puede servir como cierre, pero no sustituye a mencionar los elementos que razonablemente podrían generar confusión.

También es posible convertir una exclusión en opción. Si el cliente aún no sabe si necesita migrar todo el histórico, la propuesta puede separar el proyecto principal de esa migración en lugar de fingir que la decisión está tomada.

12. Elegir entre presupuesto cerrado, rango o fase de análisis

El formato de la estimación debería responder al nivel de incertidumbre, no a una preferencia aplicada a todos los proyectos.

Presupuesto cerrado

Tiene sentido cuando las acciones principales, las reglas, las responsabilidades y las dependencias están suficientemente claras. Pueden quedar detalles menores, pero no incógnitas capaces de cambiar la naturaleza del trabajo.

Rango estimado

Es útil cuando persiste cierta variación, pero se entienden sus límites. La propuesta debería explicar qué condiciones acercan el proyecto al extremo inferior o superior del rango. Un rango sin motivos es solo una cifra imprecisa.

Fase de análisis o discovery

Conviene cuando una incógnita crítica impide estimar la implementación con responsabilidad: por ejemplo, no se sabe si un sistema heredado permite extraer los datos o si la API del proveedor cubre el flujo imprescindible. El resultado de esa fase debe estar definido: revisión, decisiones, riesgos y una base para estimar el siguiente trabajo.

No todos los proyectos requieren discovery. Una web informativa bien definida puede presupuestarse directamente. El análisis separado es una herramienta para resolver incertidumbre real, no un paso obligatorio que añadir a cualquier encargo.

13. Acordar qué ocurre cuando cambia el alcance

Los proyectos cambian. El cliente entiende mejor su necesidad al ver una pantalla funcionando, aparece una nueva restricción o un tercero modifica una condición. El objetivo no es impedir el cambio, sino gestionarlo antes de que altere silenciosamente precio y plazo.

Conviene distinguir:

• Corrección: el resultado no cumple lo acordado o tiene un fallo.
• Ajuste dentro del alcance: concreta un detalle previsto sin cambiar el comportamiento principal.
• Nuevo requisito: añade una acción, regla, variante, integración o responsabilidad que no estaba incluida.

Cuando aparece un nuevo requisito, primero se identifica el impacto y después se decide si se sustituye otra parte, se amplía el presupuesto o se mueve a una fase posterior. Implementarlo inmediatamente y discutir el coste al final perjudica a todas las partes.

El problema no es que el proyecto cambie; es que cambie sin que nadie actualice las expectativas.

14. Qué revisa Projectia antes de dar una estimación a una agencia

Para que una agencia pueda preparar su propuesta, Projectia revisa el contexto disponible y señala las preguntas que pueden afectar al alcance técnico. Normalmente necesitamos conocer:

• Fase actual del proyecto y fecha objetivo.
• Brief, diseño o documentación disponible.
• Acciones y funcionalidades principales.
• Contenido que deberá ser editable.
• Integraciones y sistemas externos.
• Entorno técnico actual si el proyecto ya existe.
• Dependencias, accesos y terceros implicados.
• Datos, importaciones o migraciones necesarias.
• Responsabilidades de agencia, cliente y equipo técnico.
• Suposiciones e incógnitas todavía abiertas.

No es necesario llegar con todas las decisiones técnicas resueltas. Sí hace falta suficiente contexto para separar lo que puede estimarse de lo que debe investigarse.

Cuando la información necesaria está disponible, Projectia puede revisar viabilidad y alcance y preparar una estimación o presupuesto en 24–72 horas para que la agencia avance con su propuesta. Ese plazo se refiere a la preparación de la valoración, no al tiempo de entrega del proyecto ni a un SLA contractual.

En desarrollo web para agencias explicamos cómo podemos participar en esa validación y en la ejecución técnica sin desplazar la relación de la agencia con su cliente.

15. Checklist antes de enviar la propuesta al cliente

Esta lista no exige tenerlo todo cerrado. Sirve para comprobar que las incógnitas importantes son visibles antes de comprometer alcance, precio y timing.

• El objetivo del proyecto está claro.
• Las acciones principales de cada tipo de usuario están definidas.
• El contenido editable y su forma de gestión están identificados.
• Las reglas de negocio relevantes están documentadas.
• Las integraciones indican sistemas, datos, dirección y frecuencia.
• Las limitaciones del sistema existente se han revisado o marcado como pendientes.
• La preparación, carga y validación de contenidos y datos tienen responsable.
• Las dependencias de terceros están identificadas.
• Las suposiciones utilizadas para estimar están escritas.
• Las exclusiones son explícitas y comprensibles.
• La revisión y aceptación final tienen responsable.
• Las incógnitas capaces de cambiar la estimación están señaladas.
• El formato del presupuesto refleja el nivel real de incertidumbre.
• Existe un criterio para gestionar cambios de alcance.

Si varias casillas no pueden marcarse, no siempre hace falta detener la propuesta. Puede bastar con convertir esas respuestas pendientes en supuestos, dependencias, opciones o una fase previa de análisis.

16. Conclusión

Un buen presupuesto técnico no es el que tiene la hoja de cálculo más detallada. Es el que permite que agencia, cliente y equipo de desarrollo entiendan qué se va a construir, sobre qué suposiciones se está estimando, qué sigue siendo incierto, quién asume cada responsabilidad y qué puede modificar el alcance.

La agencia no necesita fingir que conoce todas las respuestas. Necesita evitar que una pregunta abierta se transforme sin querer en una promesa cerrada.

Cuanto antes se detecta una incógnita, menos probable es que se convierta en un problema después de vender el proyecto.