Resumen:
- Sin un documento común, las tres cotizaciones no son comparables.
- Dos o tres páginas bien escritas valen más que una junta de dos horas.
- Pregunta qué parte del proyecto les parece más riesgosa.
- La cotización más baja casi siempre cotizó menos cosas, no mejor precio.
- Habla con un cliente anterior; vale más que cualquier portafolio.
Un cliente nos mostró tres cotizaciones para el mismo sistema: 95,000, 340,000 y 610,000 pesos. Su pregunta era cuál era el precio justo.
No era la pregunta correcta. Las tres cotizaban proyectos distintos, porque las tres habían salido de una junta de una hora donde cada una entendió algo diferente. La de 95,000 cotizó un panel de administración; la de 610,000 cotizó eso más migración, aplicación móvil y dos integraciones. Comparar los números no significaba nada.
El documento que hace comparables las cotizaciones
Dos o tres páginas, escritas por ti, iguales para todos. No un pliego formal: un documento honesto con cinco secciones.
El problema. Qué duele hoy, en operación, con números. «Tres personas dedican cuatro horas diarias a capturar pedidos de WhatsApp en el sistema de almacén, y se pierden entre dos y cuatro pedidos por semana.» No «necesitamos digitalizarnos».
Quién lo va a usar. Cuántas personas, con qué rol, desde dónde, con qué equipo. Diez vendedores en celular con señal irregular es un proyecto distinto de tres capturistas en escritorio.
Lo imprescindible. Cinco a diez funciones sin las cuales el sistema no sirve. Si la lista pasa de quince, no es una primera versión.
Lo que queda fuera. La sección que nadie escribe y la que más ordena las cotizaciones. «En esta etapa no hay aplicación móvil, no hay facturación automática y no se migra el histórico de más de dos años.» Cada línea aquí elimina una interpretación distinta.
Con qué se conecta. Nombre y versión de los sistemas que existen y con los que hay que hablar.
Y pide que la respuesta venga desglosada en fases, con horas o días por fase y un entregable verificable en cada una. Un número total sin desglose no se puede evaluar ni negociar.
¿Cómo pido cotizaciones que sí se puedan comparar?
Entregando a todos el mismo documento de dos o tres páginas con el problema, los usuarios, las funciones imprescindibles y lo que explícitamente queda fuera, y pidiendo que la respuesta desglose fases, horas y entregables. Sin ese documento, cada proveedor cotiza un proyecto distinto y los números no son comparables.
Las cuatro preguntas de la llamada
«Si la persona que conozco se va del equipo, qué pasa con mi proyecto.» Busca una respuesta con mecanismo: documentación, código en tu repositorio, más de una persona que conozca el proyecto. «No se va a ir» no es una respuesta.
«Quién se queda con el código y los accesos.» Debe contestarse en una frase, sin incomodidad. Una pausa aquí es información valiosa.
«Cómo voy a ver el avance cada quince días.» La respuesta correcta es un ambiente de pruebas donde tú entras con tu usuario. Un reporte en porcentaje no es avance verificable.
«Qué parte de este proyecto te parece la más riesgosa.» La mejor pregunta de las cuatro. Quien ha pensado el proyecto nombra algo concreto: la integración con el sistema viejo, la calidad de los datos, el ambiente del banco. Quien contesta «ninguna, lo hemos hecho muchas veces» no lo ha pensado, o no quiere decirlo.
¿Qué preguntas debo hacer antes de contratar a un desarrollador?
Cuatro valen más que el resto: qué pasa si la persona que conozco se va del equipo, quién se queda con el código y los accesos, cómo me van a mostrar el avance cada quince días, y qué parte de este proyecto consideras la más riesgosa. La última es la más reveladora: quien no tenga una respuesta concreta no ha pensado el proyecto.
Freelance, agencia o equipo propio
| Freelance | Agencia | Equipo propio | |
|---|---|---|---|
| Costo | El más bajo | Medio a alto | El más alto, y fijo |
| Riesgo principal | Se detiene si la persona falta | Rotación interna, menos grave | Contratar y retener |
| Buen ajuste | Proyectos chicos y acotados | Proyectos con integraciones | El software es tu producto |
| Después de entregar | Depende de su disponibilidad | Contrato de soporte | Continuo |
¿Conviene contratar un freelance, una agencia o un equipo interno?
Un freelance es más barato y funciona bien para proyectos chicos y acotados, con el riesgo de que si se enferma o se va, el proyecto se detiene. Una agencia cuesta más y da continuidad y respaldo. Un equipo interno solo tiene sentido cuando el software es el producto que vendes, no una herramienta de apoyo.
Qué hacer con la cotización más baja
No descartarla, investigarla. Pon las tres cotizaciones una al lado de la otra y marca qué conceptos aparecen en unas y no en otras. Lo que suele faltar en la barata: migración de datos, pruebas, despliegue a producción, capacitación, garantía, documentación.
Si al sumar esos faltantes la barata llega al precio de la media, el precio de mercado es la media y la barata era un presupuesto incompleto. Si no llega, encontró un camino más simple y vale la pena entender cuál: a veces es la mejor opción de las tres.
¿Es mala señal que una cotización sea mucho más barata que las otras?
Es una señal de que entendió un alcance distinto, y vale la pena averiguar cuál antes de descartarla. A veces encontró un camino más simple que es legítimamente mejor. Las más de las veces no incluyó migración de datos, pruebas, capacitación o despliegue, y esos faltantes aparecen como costos extra después.
La referencia que de verdad importa
Pide hablar con un cliente de un proyecto parecido, terminado hace más de un año. Esa última condición es la que filtra: cualquiera tiene un cliente contento la semana de la entrega.
Y a ese cliente hazle dos preguntas: qué salió distinto de lo planeado, y cómo respondieron cuando algo se rompió en producción. Nadie tiene proyectos donde todo salió como estaba escrito. La diferencia entre un buen proveedor y uno malo no es que no haya problemas: es qué pasa cuando los hay.
¿Debo pedir ver código de proyectos anteriores?
Pide ver un sistema funcionando y habla con el cliente que lo usa, que dice más que el código. Si puedes revisar un repositorio de ejemplo, lo que buscas no es elegancia: es que haya pruebas automatizadas, que exista un archivo de instrucciones para levantar el proyecto y que los cambios estén registrados con mensajes legibles.
Cómo terminó el caso de las tres cotizaciones
El cliente escribió el documento de tres páginas y volvió a pedir. Las nuevas cifras: 280,000, 310,000 y 395,000. Una dispersión del 41 por ciento en vez del 542 por ciento original, y ahora sí comparables.
Eligió la de 310,000, que no era la más baja. La razón fue la cuarta pregunta: era la única que había identificado que el sistema anterior no tenía manera documentada de exportar los datos, y la única que había puesto una fase pagada para resolver eso antes de comprometer el resto del precio.