Hay una asimetría de información que complica mucho las decisiones de compra en desarrollo web. El cliente sabe lo que quiere conseguir. El proveedor sabe cómo se hace. Y entre medias hay un espacio donde ocurren la mayoría de los malentendidos, los proyectos que no salen como se esperaba y las facturas que se disparan sin que nadie entienda muy bien por qué.
La forma más efectiva de reducir esa asimetría no es convertirse en experto técnico antes de pedir un presupuesto. Es hacer las preguntas correctas. Las que revelan cómo trabaja realmente el proveedor, qué prioriza y qué va a pasar cuando las cosas no salgan exactamente como estaban previstas.
TL;DR
— La mayoría de los problemas en proyectos de desarrollo web son predecibles si se hacen las preguntas correctas antes de firmar.
— Estas cinco preguntas no requieren conocimientos técnicos pero revelan con claridad el nivel de madurez del proveedor.
— Un buen proveedor responde a todas con precisión y sin incomodidad. Uno que evita o generaliza ya te está diciendo algo.
Pregunta 1: ¿De quién será el código cuando termine el proyecto?
Esta pregunta parece obvia. La respuesta no siempre lo es.
Hay proveedores que trabajan con frameworks propietarios, con constructores visuales de licencia privada o con componentes que son suyos y no se transfieren con el proyecto. En esos casos, el cliente recibe una web que funciona pero que no puede mantener, modificar ni traspasar a otro desarrollador sin perder funcionalidades o pagar licencias adicionales.
La respuesta que buscas es inequívoca: el código desarrollado específicamente para tu proyecto es tuyo. Puedes llevarlo a otro proveedor, puedes modificarlo, puedes hacer con él lo que necesites. Sin condiciones ni asteriscos.
Si la respuesta incluye matices del tipo “depende de los componentes” o “hay partes que son de nuestra plataforma”, profundiza antes de firmar. Esos matices pueden convertirse en dependencias costosas a largo plazo.
Pregunta 2: ¿Qué documentación entregáis con el proyecto?
Un proyecto de desarrollo web sin documentación es un proyecto que solo puede mantener quien lo construyó. Si ese proveedor no está disponible en el futuro —porque cambia de precio, porque desaparece, porque simplemente no tenéis tiempo de coordinarnos— empezáis prácticamente desde cero.
La documentación mínima que debería acompañar cualquier proyecto serio incluye: descripción de la arquitectura del sistema, instrucciones para el entorno de desarrollo, documentación de las integraciones y APIs usadas, y guía para las tareas de mantenimiento más habituales.
Un proveedor que no documenta no es necesariamente deshonesto. Puede ser simplemente que trabaja rápido y sin procesos. Pero el resultado para el cliente es el mismo: dependencia.
Lo que la respuesta revela
Si el proveedor responde con precisión —”entregamos un documento de arquitectura, un README con instrucciones de entorno y un manual de usuario para las funcionalidades a medida”— estás hablando con alguien que trabaja con procesos. Si la respuesta es vaga o el tema parece incómodo, es una señal de que la documentación no es parte habitual de su forma de trabajar.
Pregunta 3: ¿Cómo gestionáis los cambios de alcance durante el proyecto?
En casi todos los proyectos de desarrollo, el cliente pide algo que no estaba en el briefing inicial. No por falta de planificación, sino porque es imposible anticipar todos los detalles antes de ver el proyecto tomar forma. La pregunta no es si va a ocurrir, sino cómo se gestiona cuando ocurre.
Un proveedor maduro tiene un proceso definido: el cambio se evalúa, se cotiza, se aprueba antes de ejecutarse. Hay transparencia sobre el impacto en plazo y coste antes de que nadie empiece a trabajar en lo nuevo.
Un proveedor sin proceso definido absorbe los cambios sin decir nada hasta que el proyecto termina y la factura final no se parece a la inicial, o los va rechazando uno a uno generando tensión con el cliente.
Ninguna de las dos situaciones es buena. Lo que quieres es un proceso claro acordado antes de empezar.
Pregunta 4: ¿Qué incluye el soporte después de la entrega y durante cuánto tiempo?
El lanzamiento no es el final del proyecto. Es el momento en que el proyecto empieza a vivir en condiciones reales, con tráfico real, con usuarios reales que hacen cosas que nadie anticipó en las pruebas.
Siempre aparece algo después del lanzamiento. Un comportamiento inesperado en un dispositivo concreto. Un error que solo ocurre bajo ciertas condiciones. Una integración que falla con datos reales que no existían en el entorno de pruebas. Lo que diferencia a los proveedores no es si esto ocurre, sino cómo responden cuando ocurre.
Qué deberías esperar
Un período mínimo de garantía post-lanzamiento —habitualmente entre 30 y 90 días— en el que los errores atribuibles al desarrollo se corrigen sin coste adicional. Y una propuesta clara de qué pasa después de ese período: si hay un contrato de mantenimiento, con qué tiempos de respuesta y a qué coste.
Si el proveedor no tiene una respuesta clara a esta pregunta, estás asumiendo un riesgo que no has cotizado.
Pregunta 5: ¿Podéis mostrarme un proyecto similar al mío que hayáis entregado?
No un portfolio genérico. Un proyecto concreto, con una descripción honesta de los retos que tuvo y cómo se resolvieron, y a poder ser con la posibilidad de hablar con el cliente de ese proyecto si tienes dudas.
Esto filtra rápidamente a los proveedores que tienen experiencia real en el tipo de proyecto que necesitas de los que tienen experiencia general pero nunca han resuelto algo parecido a lo tuyo.
Un proveedor que ha hecho integraciones con ERP puede mostrar cómo lo hizo, qué problemas aparecieron y qué se aprendió. Uno que nunca lo ha hecho puede presentarlo como si fuera sencillo porque no sabe exactamente con qué se va a encontrar.
Cómo interpretar la respuesta
La mejor respuesta es un ejemplo concreto con contexto real. La segunda mejor es honestidad: “no hemos hecho exactamente esto, pero hemos resuelto problemas similares en estos proyectos y esto es lo que aprendimos.” Lo que no queremos es una respuesta genérica que evita la pregunta o un portfolio de capturas de pantalla sin ningún contexto sobre cómo se construyó lo que se ve.
Checklist: señales de un proveedor técnico maduro
- Responde a todas las preguntas anteriores con precisión y sin incomodidad.
- Hace preguntas antes de presupuestar, no después.
- El presupuesto detalla el alcance con suficiente precisión para saber exactamente qué incluye y qué no.
- Propone un proceso de validación antes del lanzamiento, no solo una entrega final.
- Tiene referencias de clientes dispuestos a hablar sobre su experiencia.
- Es capaz de decirte cuándo algo no tiene sentido o cuándo hay una solución mejor a la que pediste.
Preguntas frecuentes
¿Es normal que el proveedor no quiera revelar detalles técnicos antes de firmar?
Hasta cierto punto, sí. Ningún proveedor va a compartir su metodología completa antes de que haya un acuerdo. Pero las cinco preguntas de este artículo no piden secretos técnicos: piden información sobre procesos, condiciones contractuales y experiencia previa. Un proveedor que se niega a responder estas preguntas antes de firmar está poniendo sus intereses por encima de los tuyos desde el principio.
¿Qué pasa si el proveedor más barato responde bien a todas las preguntas?
Que probablemente es una buena opción. El precio no es el único indicador de calidad, y hay proveedores que trabajan bien y cobran menos porque tienen estructuras de coste más eficientes o porque están en una fase de crecimiento donde priorizan construir cartera. Las preguntas no están diseñadas para eliminar a los proveedores económicos, sino para eliminar a los que no tienen procesos claros independientemente de su precio.
¿Cuándo es el mejor momento para hacer estas preguntas?
Antes de pedir el presupuesto, si es posible. Muchas de estas preguntas pueden hacerse en la primera conversación o reunión exploratoria. Hacerlas en ese momento tiene dos ventajas: te ayuda a decidir si vale la pena seguir adelante con ese proveedor antes de invertir más tiempo, y le indica al proveedor que eres un cliente que sabe lo que pide, lo que suele traducirse en un trato más profesional desde el principio.
En Baqueiro respondemos a estas cinco preguntas antes de que las hagas, porque forman parte de cómo explicamos cómo trabajamos desde el primer contacto. Si tienes un proyecto en mente y quieres empezar con el pie derecho, hablamos.
También te puede interesar: El coste real de una web barata · Cuándo externalizar y cuándo contratar · Cómo saber si tu agencia actual te está sirviendo bien