La mayoría de proyectos de software que fallan no fallan por el código. Fallan porque nadie hizo las preguntas correctas antes de firmar: nadie definió el alcance con claridad, nadie preguntó qué pasa si el proyecto se extiende y nadie verificó si el equipo entendía el problema de negocio antes de empezar a programar.
Alcance y propiedad: las dos que se negocian antes de firmar
Si la propiedad del código no está en el contrato, no estás comprando un activo.
Pregunta cómo definen el alcance antes de desarrollar. Un equipo serio invierte tiempo en entender tu proceso antes de escribir una línea: entrevistas, mapeo de flujos, definición clara de qué incluye y qué no. Si te pasan una cotización genérica sin haber entendido tu proceso, probablemente terminarás con un sistema que no encaja.
Y pregunta quién es dueño del código al final. Debe estar explícito desde el inicio, no negociarse después. Un desarrollo a medida solo funciona como inversión de largo plazo si tu empresa es dueña completa del código y no queda atada a un único proveedor para mantenerlo.
Cambios de alcance y forma de trabajo
Un proyecto que solo se ve al final es un riesgo, no una entrega.
Los cambios de alcance son normales: casi ningún proyecto termina exactamente como se definió. Lo que hay que preguntar es cómo se manejan: si existe un proceso claro para evaluar y cotizar cambios, o si cualquier ajuste se convierte en una negociación confusa a mitad de camino.
Pregunta también con qué frecuencia hay entregas visibles. Un proyecto que solo se muestra al final es un riesgo alto: si algo se está construyendo mal, lo descubres demasiado tarde. Busca equipos con entregas incrementales que puedas ver y probar.
Tecnología, soporte y comunicación
El lanzamiento no es el final del proyecto: es el inicio de la vida real del sistema.
No necesitas ser experto técnico para preguntar por qué eligieron cierta tecnología para tu caso. Un buen equipo puede explicarlo en términos simples: encaja con tus necesidades de escalabilidad, mantenimiento y presupuesto, no porque esté de moda.
Pregunta explícitamente qué pasa después del lanzamiento: si incluye soporte, por cuánto tiempo, qué ocurre ante un error crítico en producción y cómo se cotiza el mantenimiento. Y define la comunicación: un desarrollo puede tomar meses, y necesitas saber si tendrás visibilidad constante o si vas a desaparecer del radar hasta que «esté listo».
Las preguntas y cómo se ve una buena respuesta
La respuesta importa menos que su nivel de concreción.
Usa esta tabla como guion de la primera reunión. No busques la respuesta perfecta: busca respuestas específicas.
| Pregunta | Buena señal | Señal de alerta |
|---|---|---|
| ¿Cómo definen el alcance? | Diagnóstico previo con mapeo del proceso | Cotización cerrada sin conocer tu operación |
| ¿Quién es dueño del código? | Queda explícito en el contrato | «Eso lo vemos al final» |
| ¿Cómo manejan los cambios? | Proceso definido para evaluarlos y cotizarlos | Se resuelve sobre la marcha |
| ¿Cada cuánto hay entregas? | Avances revisables cada pocas semanas | Una sola entrega al cierre |
| ¿Qué pasa tras el lanzamiento? | Soporte con alcance y tiempos definidos | No se menciona |
| ¿Pueden mostrar trabajo anterior? | Proyectos de complejidad comparable | Ningún ejemplo verificable |
Señales de alerta que deberían hacerte dudar
Casi todas las señales de alerta son formas distintas de ambigüedad.
Ninguna de estas es descalificatoria por sí sola, pero dos o más juntas sí lo son:
- Precio cerrado sin haber entendido a fondo tu proceso.
- Ambigüedad sobre quién es dueño del código al finalizar.
- Plazos extremadamente cortos para proyectos con integraciones complejas.
- Cero mención del soporte posterior, como si no fuera parte de la conversación.
- Ningún ejemplo verificable de trabajo anterior.
Cómo se ve un proceso de contratación bien hecho
Diagnóstico, alcance escrito, hitos revisables y contrato claro. En ese orden.
Empieza con un diagnóstico que entienda tu proceso real, no solo lo que crees que necesitas construir. Sigue con una propuesta de alcance clara: qué incluye, qué no, tiempos estimados y cómo se manejan los cambios.
Después, un plan de trabajo con hitos visibles que puedas validar en el camino, un contrato explícito sobre propiedad del código y soporte, y una comunicación definida: con qué frecuencia habrá actualizaciones y por qué canal.
Preguntas frecuentes
¿Es mejor contratar un freelancer o una agencia?
Depende de la complejidad y de qué tan crítico sea el proyecto. Un freelancer puede bastar para proyectos pequeños y acotados; para sistemas críticos con integraciones complejas, un equipo completo con desarrollo, diseño y pruebas reduce el riesgo de depender de una sola persona.
¿Debo tener el proyecto completamente definido antes de contactar a un desarrollador?
No es necesario. Un buen equipo ayuda a definir el alcance durante el diagnóstico inicial. Sí ayuda tener claro el problema de negocio que quieres resolver, aunque la solución técnica exacta aún no esté definida.
¿Cuánto debería costar una reunión de diagnóstico inicial?
La mayoría de agencias serias ofrecen esa primera conversación sin costo, como parte de evaluar si hay un buen encaje para trabajar juntos antes de cotizar formalmente.
¿Qué garantías debo pedir en el contrato?
Como mínimo: propiedad completa del código al finalizar, un periodo de soporte post-lanzamiento incluido y claridad sobre cómo se cotizan cambios de alcance o funcionalidades adicionales.
¿Cómo sé si el equipo entendió mi problema?
Si después de la primera reunión pueden explicarte tu propio proceso con sus palabras y de forma precisa, es buena señal. Si solo repiten en términos genéricos lo que tú dijiste, probablemente no profundizaron lo suficiente.
Resumen: lo que hay que recordar
- Alcance, propiedad del código, manejo de cambios y soporte posterior: las cuatro que van por escrito.
- Un proyecto sin entregas intermedias esconde los errores hasta que ya son caros de corregir.
- La respuesta vaga es el dato: mide la concreción, no la simpatía de la reunión de ventas.
¿Vas a contratar un desarrollo a medida?
Empezamos cada proyecto entendiendo el proceso de negocio real antes de proponer una sola línea de alcance técnico.
Ver servicio de desarrollo web
