Qué incluye una propuesta de desarrollo web (y qué debería incluir pero no siempre está)

Recibir una propuesta de desarrollo web sin saber qué buscar es como leer un contrato en un idioma que no hablás. Esta guía te dice qué tiene que estar y qué ausencias son señales de alerta.

Cuando recibís una propuesta de desarrollo web, hay información que debería estar siempre y que determina si el proyecto va a salir como esperás o si vas a tener sorpresas desagradables en el camino.

Este artículo es el checklist que deberías tener en la mano cuando estás leyendo la próxima propuesta.

Lo que siempre tiene que estar

Descripción del alcance con nivel de detalle suficiente

La propuesta debería describir exactamente qué se va a construir: cuántas páginas, qué secciones tiene cada una, qué funcionalidades incluye (formularios, sistema de turnos, galería, blog), qué integraciones están incluidas (analytics, WhatsApp, pasarela de pagos).

"Sitio web profesional completo" no es un alcance — es una frase de marketing. Si el alcance es vago, lo que está incluido y lo que no está incluido va a ser objeto de disputa durante el proyecto.

Señal de alerta: una propuesta que describe el proyecto en un párrafo sin detalle de páginas, secciones y funcionalidades.

Desglose de hitos y plazos

¿Cuándo empieza el diseño? ¿Cuándo está listo para la primera revisión? ¿Cuándo arranca el desarrollo? ¿Cuándo es el lanzamiento estimado?

Un proyecto sin fechas no tiene urgencia. Y un proyecto sin urgencia se extiende indefinidamente.

El cronograma también te permite ver qué depende de vos: si necesitás entregar materiales (fotos, textos) antes de cierta fecha para que los plazos se cumplan, eso tiene que estar explícito.

Rondas de revisión incluidas

Cuántas revisiones de diseño están incluidas, en qué etapas, y qué pasa si querés más. Estándar en el mercado: 2 rondas de diseño y 1 de desarrollo. Si la propuesta no especifica esto, podés terminar en un ciclo interminable o con un costo extra sorpresivo.

Qué se entrega y a quién pertenece

Al finalizar el proyecto, ¿qué recibís exactamente? ¿Los accesos al hosting? ¿El código fuente? ¿El acceso a Google Analytics? ¿Quién es el dueño del dominio?

Todo esto debería estar en la propuesta. Si no está, preguntá antes de firmar.

Estructura de pagos

Cuándo se paga qué. El estándar razonable: 50% al inicio, 50% al lanzamiento. Proyectos grandes pueden tener tres pagos. La propuesta debería especificarlo con fechas o hitos claros.

Soporte post-lanzamiento

¿Qué pasa después del lanzamiento? ¿Hay un período de garantía de bugs? ¿Cuánto tiempo? ¿Qué cuesta el soporte si necesitás cambios después?

Si la propuesta no menciona nada sobre lo que pasa después del lanzamiento, es una señal de que el proveedor trabaja en modo "entrego y desaparezco".

Lo que debería estar pero a menudo no está

Qué necesitás vos de tu lado y para cuándo

Las demoras en proyectos web casi siempre tienen una causa del lado del cliente: materiales que no llegaron a tiempo, feedback que tardó, decisiones que no se tomaron. Una buena propuesta especifica exactamente qué materiales necesita el proveedor y para qué fecha.

Cómo se va a medir el éxito del proyecto

¿Cuáles son las métricas que van a usar para saber si el sitio está funcionando? Si la propuesta no menciona analytics, eventos de conversión ni ningún mecanismo de medición, es probable que construyan algo que "queda bien" sin preocuparse por si genera resultados.

Qué NO está incluido

Las propuestas que solo describen lo que sí incluyen ocultan los puntos de conflicto. Las mejores propuestas también explican explícitamente qué no está en el alcance: "el copywriting no está incluido", "las integraciones con sistemas externos fuera de las mencionadas tienen cotización adicional", "la producción de fotografías no está incluida".

Esa claridad previene malentendidos y disputas.

El proceso de manejo de cambios de scope

Si durante el proyecto aparecen nuevas páginas o funcionalidades, ¿cómo se manejan? ¿Hay un proceso formal? ¿Un precio por hora? ¿Un mínimo de scope para cotizar un cambio?

Sin proceso definido, cada cambio fuera del scope es una negociación en la que ninguno de los dos sabe bien qué esperar.

Lo que no debería estar (señales de alerta)

Garantías de posicionamiento en Google. Nadie puede garantizarlo. Si está en la propuesta, algo no cuadra.

Precios sin contexto. Un número sin desglose de qué incluye no es una propuesta — es un precio al aire.

Timelines irrealistas. Si prometen una web compleja en 3 días, hay algo que no están diciendo sobre la complejidad del resultado o el proceso que van a seguir.

Sin proceso de revisión descrito. Si no hay revisiones formales en el proceso, el cliente no tiene momentos definidos para dar feedback y el resultado puede divergir mucho de las expectativas.

En TuWebAI nuestras propuestas incluyen todo lo que describimos acá y explicamos explícitamente qué no está incluido. Si querés ver cómo es el proceso, empezamos con una consulta sin costo. Hablemos →