Tu proveedor técnico acaba de enviarte el entregable: un enlace de staging, acceso al repositorio o un archivo ZIP con el sitio listo. Ahora toca tu parte: revisarlo y aprobarlo antes de que pase al cliente final. El problema es que no eres programador y no sabes exactamente qué revisar más allá de que "se vea bien".
Esta guía es para eso. No vas a aprender a leer código —tampoco lo necesitas—. Lo que sí vas a poder hacer, con este checklist, es detectar los problemas que importan: los que el cliente va a notar el primer día, los que pueden comprometer datos o accesos, y los que indican que el trabajo está incompleto.
Lo que sí puedes revisar sin saber programar
La mayoría de los problemas en un entregable de desarrollo no están ocultos en el código. Están a la vista: un formulario que no envía, una imagen que no carga en celular, un acceso que sigue siendo del proveedor y no del cliente. Todo eso lo puedes ver tú, con un navegador y una conexión a internet.
Lo que no puedes revisar sin conocimiento técnico —y no deberías fingir que puedes— es la calidad del código en sí: si está bien estructurado, si tiene deuda técnica, si las consultas a la base de datos son eficientes. Para eso existe la auditoría técnica, que es diferente a la revisión de entrega. Esta guía cubre la revisión de entrega, que sí es tu responsabilidad como intermediario entre tu proveedor y tu cliente.
Checklist en cuatro capas
Organiza la revisión en cuatro bloques. Cada uno cubre riesgos distintos.
Capa 1 — Visual y responsive
- ¿El sitio se ve como fue acordado en el brief o en los mockups aprobados?
- ¿Funciona en celular? Pruébalo en tu propio dispositivo, no solo en el escritorio.
- ¿Las imágenes cargan correctamente? ¿Hay alguna rota o pixelada en pantalla pequeña?
- ¿Los textos no tienen errores ortográficos visibles ni contenido de marcador (Lorem ipsum, "Aquí va el texto del cliente")?
- ¿Los colores, tipografías y logotipo corresponden a la marca del cliente?
Capa 2 — Funcional
- ¿Todos los botones llevan a donde deben? Haz clic en cada uno.
- ¿Los formularios de contacto envían el mensaje y llegan al correo correcto?
- ¿Los enlaces internos y externos abren sin error 404?
- ¿La navegación del menú funciona en celular y en escritorio?
- ¿Las animaciones o efectos visuales no interrumpen el uso ni hacen el sitio lento?
Capa 3 — Accesos y propiedad
Esta es la capa más crítica y la más ignorada. Un entregable puede verse impecable y aun así tener un problema serio: que el proveedor siga siendo dueño de los accesos.
- ¿El dominio y el hosting están bajo la cuenta del cliente, no del proveedor?
- ¿El cliente tiene acceso de administrador al panel del sitio (WordPress, CMS o lo que aplique)?
- ¿El repositorio de código está en una cuenta del cliente o de tu agencia, no en la del proveedor?
- ¿Las cuentas de correo, Google Analytics o servicios de terceros tienen al cliente como propietario?
- ¿El proveedor tiene acceso temporal que se puede revocar, no permanente e irremovible?
En el modelo de desarrollo white label para agencias, el código y los accesos quedan en manos del cliente desde el primer día, no al momento del cierre. Si eso no ocurrió, es una conversación que tienes que tener con tu proveedor antes de aprobar.
Capa 4 — Documentación
- ¿El proveedor entregó documentación de accesos (usuario, contraseña, URL del panel)?
- ¿Hay una descripción de las tecnologías usadas? Aunque no las conozcas, el cliente puede necesitarla.
- ¿Existe alguna guía básica para hacer cambios menores, como actualizar un texto o agregar una imagen?
- ¿Están documentadas las integraciones de terceros (formularios, Google Analytics, pasarela de pago)?
Un entregable sin documentación no está completo, aunque funcione perfectamente. Si tu proveedor no incluye esto por defecto, es una condición que deberías pedir antes de firmar el acuerdo de trabajo.
Herramientas gratuitas para ir más allá de lo visual
Dos herramientas públicas te permiten revisar aspectos técnicos básicos sin saber programar:
- Google PageSpeed Insights (pagespeed.web.dev): Pega la URL del sitio y mide el tiempo de carga en celular y escritorio. No tienes que entender todos los números, pero si el puntaje en celular está por debajo de 50, hay un problema que afectará la experiencia del cliente final.
- Google Search Console (search.google.com/search-console): Una vez que el dominio esté verificado, muestra si hay errores de indexación, páginas no encontradas o problemas de cobertura. Es la misma herramienta que Google usa para evaluar el sitio.
Estas no reemplazan una auditoría técnica, pero sí te dan datos reales para hablar con tu proveedor desde hechos concretos, no desde intuiciones.
Las tres preguntas que debes hacerle al proveedor al recibir el entregable
Más que revisar en silencio, tienes derecho a preguntar. Estas tres preguntas cubren lo que un proveedor serio debe poder responder sin dudar:
- ¿Qué pasos hiciste para probar el sitio antes de enviármelo? Si la respuesta es vaga o dice que solo lo revisó visualmente, es señal de que no hubo pruebas funcionales formales.
- ¿Qué pasa si encuentro un error en los próximos días? Confirma el período de garantía de correcciones y si el proceso es por correo, por ticket o por mensaje. Que esté claro antes de que aparezca el primer problema.
- ¿Hay algo que no pude terminar o que quedó pendiente? Un proveedor honesto nombra lo que no está listo. Si la respuesta es "todo está listo" y tú encuentras cosas incompletas, el problema es la comunicación, no el trabajo.
Qué registrar al cerrar la entrega
Antes de firmar la aceptación formal del entregable —o de trasladarla a tu cliente—, documenta lo que revisaste y lo que encontraste. No tiene que ser un documento extenso: una lista con las capas que revisaste, los problemas que encontraste y las respuestas del proveedor es suficiente.
Si el entregable tiene observaciones, registra la fecha en que las enviaste y la fecha en que el proveedor confirmó que las resolvió. Ese registro te protege a ti frente al cliente y al proveedor frente a cualquier disputa posterior.
El modelo white label bien ejecutado incluye este proceso como parte estándar del cierre. Si tu proveedor no tiene un proceso de entrega formal, es algo que puedes establecer tú como agencia y exigir como condición del trabajo.
En resumen: qué apruebas y qué no
Aprobar un entregable de desarrollo no significa decir que el código es excelente. Significa confirmar que el sitio funciona como se acordó, que los accesos están en manos correctas y que la documentación existe. Eso sí es responsabilidad tuya, incluso si no eres programador, y es la parte de la que tu cliente te va a pedir cuentas si algo sale mal después del lanzamiento.
Si quieres construir ese proceso de entrega con un brazo técnico para tu agencia que ya lo tenga documentado, el punto de partida es conocer cómo trabajan antes de comprometerte.
Preguntas frecuentes
¿Tengo que entender código para aprobar un entregable de desarrollo?
No. La revisión de entrega que le corresponde a una agencia no técnica cubre cuatro capas: que el sitio se vea bien en todos los dispositivos, que las funciones acordadas operen correctamente, que los accesos estén en manos del cliente y que exista la documentación básica. Todo eso lo puedes revisar con un navegador, sin leer una línea de código.
¿Qué hago si encuentro errores después de aprobar el entregable?
Depende de lo que dice el acuerdo con tu proveedor. La mayoría de los proyectos de desarrollo incluyen un período de corrección de errores después de la entrega formal. La clave es tener ese período definido por escrito antes de que empiece el proyecto, no negociarlo cuando ya apareció el problema.
¿Cuánto tiempo debo tomarse para revisar un entregable?
Depende del tamaño del proyecto. Para un sitio web de 5 a 10 páginas, una revisión con este checklist toma entre una y tres horas si lo haces con cuidado. Eso incluye probar en celular, completar todos los formularios, revisar los accesos y leer la documentación. Apurar esta etapa es una de las formas más comunes de que los problemas lleguen al cliente final.
¿El proveedor puede tener acceso permanente al sitio del cliente?
No debería. El acceso del proveedor técnico al sitio del cliente debe ser temporal y revocable: lo que necesita para hacer el trabajo, no más. Al cerrar el entregable, los únicos con acceso permanente deben ser el cliente y, si se acordó, tu agencia como administrador de confianza. Que el proveedor mantenga acceso de administrador sin que el cliente lo sepa es un riesgo operativo.
¿Qué pasa si el proveedor dice que todo está listo pero yo encuentro errores?
Es más común de lo que parece. El paso correcto es documentar los errores con capturas de pantalla, enviárselos al proveedor por escrito y establecer una fecha de corrección. Si tienes el acuerdo de trabajo por escrito con criterios de aceptación definidos, tienes base para exigir la corrección sin costo adicional. Sin ese acuerdo, la negociación es más difícil.
