6 señales de alerta en una propuesta de desarrollo web (y las preguntas exactas para detectarlas)
La mayoría de los proyectos web y móviles no fracasan por “mal código”. Fracasan porque las expectativas nunca se concretan: qué incluye, qué no, quién es dueño de qué y qué significa realmente estar “listo para lanzar”.
En Jensen Technologies llevamos muchos años construyendo sitios web y aplicaciones. Hemos visto propuestas que se ven impecables por fuera, pero que esconden riesgo detrás de frases vagas. Aquí van seis señales de alerta habituales-y preguntas simples que separan rápidamente a un equipo sólido de una apuesta arriesgada.
1) Entregables ambiguos
Señal de alerta: La propuesta promete “un sitio moderno” o “una app completa” sin desglosar entregables.
Por qué importa: Si no hay lista, no puedes comparar proveedores, controlar el alcance ni saber qué estás pagando. La ambigüedad es donde nacen los sobrecostes.
Pregunta: “¿Pueden enumerar cada entregable (páginas, plantillas, componentes, integraciones) y definir qué significa ‘terminado’ para cada uno?”
Cómo se ve lo bueno: Un inventario claro (número de plantillas, componentes reutilizables, tipos de contenido del CMS, integraciones específicas) y criterios de aceptación.
2) Hosting, propiedad y accesos poco claros
Señal de alerta: No queda claro quién es dueño del dominio, la cuenta de hosting, el código fuente, los archivos de diseño, la analítica o las cuentas de tiendas.
Por qué importa: La propiedad y los accesos determinan si puedes cambiar de proveedor, internalizar trabajo o simplemente operar si cambia la relación.
Pregunta: “En el día 1 y en el día 100, ¿qué cuentas están a nombre de nuestra empresa y cómo es el proceso de handover?”
Cómo se ve lo bueno: Tu empresa es dueña de las cuentas críticas, los accesos quedan documentados y la entrega/traspaso se trata como una parte normal (y verificable) del proyecto.
3) El scope creep es normal-pero la propuesta no lo gestiona
Señal de alerta: Muchas cláusulas de “fuera de alcance” sin un proceso práctico para evaluar y aprobar cambios.
Por qué importa: Los requisitos evolucionan. La cuestión no es si cambiarás algo, sino si el proceso se mantiene justo, predecible y rápido.
Pregunta: “¿Cómo gestionan cambios: cuál es el flujo de aprobación, el rango de coste típico y quién aprueba?”
Cómo se ve lo bueno: Un control de cambios ligero: estimación por escrito, impacto en el calendario, punto claro de aprobación y un backlog compartido de decisiones.
4) Pruebas, rendimiento y accesibilidad: ausentes o superficiales
Señal de alerta: QA aparece como una línea; accesibilidad no se menciona; el rendimiento se da por hecho.
Por qué importa: Los errores y la lentitud cuestan más después del lanzamiento. Accesibilidad y estándares básicos de calidad salen mejor (y más barato) cuando se planifican al inicio.
Pregunta: “¿Cuál es su plan de pruebas (dispositivos/navegadores), presupuesto de rendimiento y objetivo de accesibilidad (p. ej., WCAG 2.1 AA)?”
Cómo se ve lo bueno: Un proceso de QA definido, mínimo de navegadores/dispositivos soportados, objetivos de rendimiento y una postura de accesibilidad alineada con tu audiencia y riesgo.
5) Plazos sin hitos (o sin tus responsabilidades)
Señal de alerta: Una fecha final sin fases, sin checkpoints y sin lista de dependencias del cliente.
Por qué importa: Muchos retrasos vienen de dependencias: contenido, aprobaciones, assets de marca, textos legales, credenciales de cuentas, validaciones internas.
Pregunta: “¿Cuáles son los hitos, qué necesitan de nosotros y para cuándo, y qué pasa si los inputs llegan tarde?”
Cómo se ve lo bueno: Un plan por hitos (descubrimiento, wireframes, diseño, desarrollo, QA, lanzamiento) y una lista de dependencias mutuas que protege a ambas partes.
6) Soporte post-lanzamiento y SLAs vagos
Señal de alerta: “Hay soporte” sin tiempos de respuesta, sin monitoreo, sin expectativas de parches de seguridad o sin cadencia de releases.
Por qué importa: El lanzamiento es el inicio del uso real: picos de tráfico, casos límite, actualizaciones de navegador, vulnerabilidades, cambios de sistema operativo y feedback de usuarios.
Pregunta: “¿Qué niveles de soporte ofrecen, tiempos de respuesta, herramientas de monitoreo y cadencia de parches/releases?”
Cómo se ve lo bueno: Opciones de soporte claras (incluyendo canal de emergencia), monitoreo/alertas y un proceso acordado para actualizaciones y mejoras.
Una forma práctica de usar esta lista
- Envía estas preguntas en un solo email a todos los proveedores que estés evaluando.
- Compara la claridad de las respuestas, no solo el precio.
- Observa señales de evasión o vaguedad. Los equipos fuertes agradecen la especificidad.
Si quieres hablar de alguno de estos puntos-o necesitas una segunda opinión sobre una propuesta que has recibido-ponte en contacto con Jensen Technologies. Estaremos encantados de ayudarte a revisar el alcance y a preparar tu proyecto para un desarrollo y un lanzamiento sin sorpresas.