Entregables que todo cliente no técnico debería exigir a un desarrollador
Cuando inviertes en una nueva web o una app móvil, no estás comprando solo un conjunto de funcionalidades. Estás comprando la capacidad de operar lo construido, mejorarlo con el tiempo y-si hiciera falta-cambiar de proveedor sin que tu negocio se paralice.
En Jensen Technologies llevamos muchos años entregando proyectos web y móviles. Los problemas más dolorosos que nos piden resolver a posteriori rara vez son “mala calidad de código” en abstracto. Casi siempre son entregables que faltan: propiedad poco clara, cero documentación de despliegue, código inaccesible o una entrega que básicamente es “escríbenos si algo se rompe”.
Este artículo es una checklist práctica que puedes usar antes de firmar una propuesta, durante el proyecto y especialmente en la entrega final.
1) Acceso y propiedad (hazlo innegociable)
Si no controlas los accesos, no controlas el producto. Asegúrate de recibir (y comprobar) lo siguiente:
- Acceso al registrador del dominio y control del DNS (o confirmación por escrito de que el dominio es tuyo y puedes migrarlo cuando quieras).
- Acceso a la cuenta de hosting/cloud (AWS/Azure/GCP/Vercel/Netlify, etc.), idealmente bajo una cuenta propiedad de tu empresa.
- Acceso al repositorio de código (GitHub/GitLab/Bitbucket) dentro de tu organización, no en un repo privado que solo controla el proveedor.
- Acceso admin a herramientas relevantes: CMS, analytics, tag manager, email, pasarela de pagos e integraciones de terceros.
- Acceso a las tiendas (Apple Developer / Google Play Console) si hay app móvil-también bajo tu empresa.
Consejo práctico: no basta con que te envíen credenciales; planifica una breve sesión de verificación para iniciar sesión y confirmar que ves lo necesario.
2) Una base de código utilizable, no solo un zip
Deberías poder levantar el proyecto de nuevo en seis meses sin adivinar nada.
- README que explique cómo ejecutar el proyecto en local y cómo compilarlo.
- Variables de entorno documentadas: qué valores existen, para qué sirven y dónde se configuran.
- Claridad de entornos: dev/staging/producción (aunque staging sea sencillo). Necesitas un lugar seguro para probar cambios antes de afectar a clientes.
Cuando alguien dice “solo funciona en mi ordenador”, normalmente faltan documentación y una configuración de entorno clara.
3) Entregables de diseño que puedas reutilizar
Incluso si “ya está el diseño”, volverás a él: nuevas landing pages, nuevos flujos, nuevas funcionalidades.
- Archivos finales de diseño (normalmente en Figma) con componentes y estilos, no solo imágenes exportadas.
- Básicos de marca: colores, tipografías, reglas de espaciado, iconos y notas de uso.
- Listado de flujos clave (registro, checkout, reserva, etc.) para que el trabajo futuro no los rompa sin querer.
4) Evidencia de pruebas (no solo “lo hemos probado”)
Las pruebas no deberían ser una caja negra. Pide evidencia clara de qué se ha probado y qué no.
- Checklist de smoke tests para el día de lanzamiento (rutas críticas que deben funcionar).
- Tests automáticos cuando aplique (unit/integration/end-to-end). Incluso un conjunto pequeño ayuda a evitar regresiones.
- Declaración de soporte de navegadores/dispositivos: qué se incluye, qué se excluye y por qué.
5) Pasos de despliegue, rollback y “dónde mirar si falla”
Muchas entregas fallan en el momento en que necesitas velocidad: un bug en producción, una campaña, un ajuste post-lanzamiento.
- Proceso de despliegue paso a paso: quién hace qué, con enlaces a pipelines o scripts.
- Procedimiento de rollback para volver a una versión estable conocida.
- Logs y monitorización: dónde están los logs, qué alertas existen y qué aspecto tiene un funcionamiento “normal”.
6) Esenciales de seguridad y cumplimiento
No necesitas un tratado legal, pero sí claridad.
- SSL/TLS habilitado y configuraciones básicas de seguridad cuando corresponda.
- Roles y permisos documentados (quién despliega, quién ve datos, quién gestiona usuarios, etc.).
- Notas sobre datos: qué datos personales se recopilan, expectativas de retención y políticas de backup.
7) Entrega de mantenimiento (cómo se mantiene sano)
El lanzamiento es el inicio de la operación, no el fin del desarrollo. Un buen proveedor deja claras las responsabilidades continuas.
- Plan de actualización de dependencias (mensual o trimestral) y cómo se gestionan vulnerabilidades.
- Backups: frecuencia, retención y confirmación de que se han probado restauraciones.
- Alertas de monitorización/uptime y lista clara de responsables.
- Plan de “primera semana post-lanzamiento” para triage de bugs, pequeños ajustes y optimización de rendimiento.
Señales de alarma sencillas en propuestas
- “Lo alojamos en nuestra cuenta por comodidad” sin propiedad explícita y condiciones de exportación/migración.
- No mencionan documentación, pruebas ni despliegue; solo funcionalidades y diseño.
- Mantenimiento vago como “según sea necesario” sin alcance, tiempos de respuesta ni exclusiones.
- Sin lista de entregables más allá de “web/app”, lo que vuelve la aceptación subjetiva y confusa.
Una entrega bien hecha se siente casi aburrida: los accesos están claros, hay documentación, y otro equipo podría continuar si tus necesidades cambian.
Si te apetece comentarlo, Jensen Technologies puede ayudarte a definir los entregables correctos para tu stack (web, móvil y productos con IA), revisar propuestas o preparar un proceso de entrega limpio. Ponte en contacto si quieres hablar del tema o necesitas ayuda para aplicarlo en tu negocio.