Qué debe incluir una propuesta para desarrollar tu web o tienda

El problema aparece después de firmar

Casi ningún proyecto web se complica en la primera reunión. Se complica en la tercera semana, cuando alguien pregunta si el formulario incluía la conexión con el CRM, si las fotos las tomaba el proveedor o si el blog venía con artículos. Cada una de esas preguntas tiene una respuesta, y lo ideal es que esté escrita en la propuesta antes de aprobarla.

Leer bien una propuesta no exige saber programar. Exige revisar seis bloques con la misma pregunta: ¿esto está escrito o lo estoy suponiendo?

Los seis bloques que debes encontrar

Alcance y entregables

El alcance bueno es una lista, no un adjetivo. Debe decir cuántas páginas o plantillas, qué funciones, qué integraciones y qué idiomas. Los entregables responden otra pregunta: qué tendrás en la mano al final. Además del sitio publicado, pide que figuren los accesos de administración a nombre de tu empresa y una forma de saber qué se construyó.

Exclusiones: la sección que más ahorra discusiones

Una propuesta que no dice qué excluye deja todo abierto a interpretación. Las exclusiones típicas son redacción de contenidos, fotografía, licencias de terceros, pauta, integraciones no listadas y cambios de diseño después de aprobado. Que algo esté excluido no es malo: lo malo es descubrirlo tarde.

Insumos, accesos y plazos

Todo plazo depende de algo que tú entregas: textos, logos, fotos, accesos al dominio. Una propuesta seria dice desde cuándo corre el reloj y qué lo detiene. En RealStack, por ejemplo, el plazo de 72 h* de Launch™, Commerce™ y Scale™ arranca con la aprobación del onboarding, con alcance estándar cerrado por escrito e insumos completos; no corre desde el pago y no aplica a cualquier desarrollo.

Medición y continuidad

Pregunta qué quedará medido el día del lanzamiento y con qué herramientas. Las cuentas de analítica deben estar a nombre de tu empresa, con acceso para el proveedor como usuario, no al revés.

En continuidad hay cuatro cosas distintas que conviene no mezclar: garantía (corrección de errores del desarrollo entregado, por un tiempo definido), alojamiento e infraestructura (que el sitio esté en línea), soporte (quién atiende solicitudes y bajo qué plan) y evolución (mejoras y funciones nuevas, que se cotizan). Si la propuesta los agrupa en una sola palabra, pide que los separe.

Procedimiento de revisión

1. Lee la propuesta completa una vez sin marcar nada.
2. En la segunda lectura, ubica los seis bloques y marca los que faltan.
3. Haz una lista de lo que estás suponiendo y no está escrito.
4. Envía esas preguntas al proveedor por escrito y pide una versión ajustada.
5. Compara la versión final con la checklist descargable antes de aprobar.

Ejemplo aplicado

Límites de esta guía

Esta guía te ayuda a revisar el contenido comercial y operativo de una propuesta. No es asesoría jurídica ni tributaria: cláusulas de responsabilidad, propiedad intelectual, impuestos y condiciones de pago deben revisarlas tu abogado o contador.

Criterios para comparar propuestas

Dos propuestas con el mismo precio pueden contener alcances muy distintos. Compararlas por precio sin normalizar el alcance lleva a elegir la que menos explica, no la que más conviene.

Ejemplo sintético completo

Ejemplo sintético. Una empresa ficticia recibe tres propuestas para su sitio corporativo. Usa la checklist y encuentra que la propuesta A detalla ocho plantillas, exclusiones y condiciones de entrega; la B promete «todo lo necesario» sin lista; la C incluye redacción de contenidos, pero no dice quién es dueño del dominio ni de la analítica.

En lugar de descartar B y C, envía a los tres proveedores las mismas preguntas: qué plantillas incluye, qué queda fuera, quién crea y administra las cuentas, qué pasa al terminar. Con las respuestas escritas, las tres propuestas se pueden comparar en igualdad. La empresa elige la que mejor responde, no la más barata. Ejemplo inventado.

Cómo usar la checklist descargable

1. Imprime o copia una checklist por propuesta.
2. Marca solo lo que esté escrito en la propuesta, no lo que te dijeron en la reunión.
3. Convierte cada casilla vacía en una pregunta para el proveedor.
4. Pide las respuestas por escrito y anéxalas a la propuesta.
5. Si hay dudas contractuales, consulta a tu asesor jurídico: esta checklist no es asesoría legal.

Preguntas para hacerle al proveedor

• ¿Qué pasa si los insumos llegan tarde: se corre el plazo o cambia el precio?
• ¿Cuántas rondas de ajustes incluye cada entrega y qué cuenta como ajuste?
• ¿Quién crea las cuentas de dominio, alojamiento y analítica, y a nombre de quién quedan?
• ¿Qué documentación y capacitación recibirá mi equipo al cierre?
• ¿Qué servicios posteriores ofrece y cómo se contratan por separado?

Diagnóstico antes de empezar

• Reúne todas las propuestas recibidas y los correos o chats donde se negoció algo.
• Anota qué esperas tener al final del proyecto, en una lista de diez líneas como máximo.
• Identifica quién firmará y quién revisará lo entregado.

Señales de que funciona o no

• Señal buena: puedes explicar en una frase qué incluye y qué no.
• Señal mala: la respuesta a tus preguntas es «eso lo vemos después».
• Mídelo tú: cuenta cuántas casillas quedaron vacías tras las respuestas escritas.

Un segundo ejemplo, en contraste

Ejemplo sintético. Una empresa ficticia recibe una sola propuesta, muy detallada, de un proveedor recomendado. Como no tiene contra qué comparar, usa la checklist como referencia: encuentra todo cubierto salvo la continuidad. En lugar de buscar otro proveedor, pide que se agregue un anexo sobre qué pasa después de la entrega. Al contrario del primer ejemplo, aquí el problema no era el alcance, sino lo que venía después. Ejemplo inventado.

Qué hacer cuando algo falla

• Si al revisar lo entregado falta algo, compáralo con el alcance escrito y comunícalo por escrito con el punto exacto.
• Si el desacuerdo es sobre algo que no estaba escrito, negócialo como cambio, no como incumplimiento.
• Si la relación se rompe, asegura primero dominio, accesos y copias.

Errores frecuentes

• Aprobar por precio sin comparar alcances equivalentes.
• Aceptar «soporte incluido» sin saber qué cubre ni por cuánto tiempo.
• No pedir los accesos a nombre de la empresa.
• Suponer que el contenido y las fotos vienen incluidos.
• Dejar la medición para después del lanzamiento.

Checklist

• El alcance enumera páginas o funcionalidades.
• Hay una lista de exclusiones.
• Están definidos los insumos y quién los entrega.
• Los plazos dicen desde cuándo corren.
• Las cuentas de dominio, alojamiento y analítica quedan a nombre de tu empresa.
• Está claro qué pasa después de la entrega.