Hay un momento en que casi todas las empresas llegan al mismo punto: decidieron que necesitan desarrollo de software, abrieron algunas propuestas, y ahora tienen que elegir a quién contratar sin tener demasiado contexto para comparar.
El problema es que las propuestas todas se ven parecidas. Todas tienen un logo prolijo, casos de éxito que suenan bien y un precio que en algún punto del proceso empieza a bajar para cerrar. Elegir bien en ese escenario requiere saber qué preguntar, no solo qué leer.
Esta guía está escrita para ese momento.
Por qué es una decisión más cara de lo que parece
La mayoría de las empresas que llegan a nosotros después de una mala experiencia con otra agencia no perdieron solo el dinero del proyecto fallido. Perdieron entre seis meses y un año de tiempo operativo, más el costo de volver a levantar los requerimientos desde cero, más el desgaste interno de un equipo que adoptó un sistema que después hubo que abandonar.
Ese es el costo real de elegir mal. No es el presupuesto que se firmó. Es todo lo que vino después.
Por eso la decisión de con quién desarrollar merece más rigor que el que generalmente se le dedica.
La primera señal de alerta: la propuesta sin diagnóstico
La señal más clara de que una agencia no va a funcionar aparece en los primeros días de contacto: te mandan una propuesta económica antes de entender bien qué necesitás.
Eso no es agilidad. Es una red de pesca.
Una propuesta que llega en 48 horas con un número y un alcance definido, antes de que alguien se haya sentado a mapear cómo opera realmente tu empresa, está basada en suposiciones. Alguien tomó lo que dijiste en la primera reunión, lo procesó con un template y te mandó un número que va a cambiar apenas empiece el desarrollo.
Una agencia que hace bien su trabajo hace preguntas antes de cotizar. Muchas preguntas. Quiere entender el proceso actual, no solo el sistema que querés. Quiere saber qué está fallando, qué equipos lo usan, qué restricciones técnicas existen, qué integraciones son necesarias. Ese proceso de diagnóstico es lo que hace que la propuesta tenga sentido, y es también lo que da una idea real de si la agencia entiende el problema o solo entiende de código.
Las preguntas que hay que hacer antes de firmar
Hay preguntas que incomodan pero que vale la pena hacer. Una agencia que trabaja bien no se ofende con ellas. Una agencia que no trabaja bien va a esquivarlas.
¿Quién va a estar a cargo de mi proyecto día a día?
Las agencias venden con su mejor gente y entregan con quien tenga disponibilidad. Preguntá por nombre y apellido. Pedí hablar con el desarrollador que va a llevar el proyecto, no solo con el comercial. Si eso genera fricción, es información útil.
¿Puedo hablar con algún cliente cuyo proyecto ya esté en producción?
Un portfolio con pantallas es fácil de armar. Una referencia real, no. Si la agencia tiene clientes satisfechos, los tiene. Si el pedido genera demoras o excusas, el portfolio probablemente no refleja la realidad.
¿Cómo se maneja el alcance cuando aparecen cambios durante el desarrollo?
Los proyectos de software siempre generan cambios. Es inevitable. La pregunta no es si van a aparecer, sino cómo se gestiona cuando aparecen. Si la respuesta es vaga o no existe una política clara, el contrato va a ser una fuente de conflicto.
¿Cuántos proyectos parecidos al mío hicieron?
"Experiencia en desarrollo web" no es lo mismo que experiencia construyendo un ERP para una distribuidora o un CRM para una empresa de servicios B2B. El contexto de negocio importa tanto como la capacidad técnica. Una agencia que hizo cinco proyectos similares al tuyo va a cometer menos errores que una que lo hace por primera vez, aunque técnicamente sea igual de competente.
¿Qué pasa con el código si termina la relación?
El código es tuyo. Siempre. Si la agencia no lo pone explícitamente en el contrato, es un problema. Y más allá del contrato: pedí que el repositorio esté en una cuenta que vos controlás desde el principio, no en la cuenta de la agencia.
Qué mirar en el portfolio (y qué ignorar)
El portfolio es lo primero que muestra cualquier agencia y, paradójicamente, lo que menos información útil suele dar.
Las pantallas de diseño se ven bien porque para eso están. Lo que no se ve en un portfolio es si el proyecto se entregó a tiempo, si el presupuesto se respetó, si el cliente tuvo que renegociar el alcance tres veces, o si el sistema está en producción y funcionando hoy.
Lo que sí vale la pena evaluar en un portfolio:
La variedad de contextos de negocio. Una agencia que solo hizo e-commerce tiene sesgos de e-commerce. Una que trabajó con distribuidoras, con empresas de servicios y con manufactura tiene más capacidad para entender negocios distintos.
Si explican el problema, no solo la solución. Los mejores casos de portfolio describen cuál era el problema operativo que tenía el cliente, qué se construyó y por qué, y qué cambió después de la implementación. Si el caso es solo "construimos una plataforma para X empresa con estas tecnologías", no dice casi nada.
Si mencionan lo que no funcionó. Ningún proyecto de software es perfecto. Una agencia que habla solo de éxitos sin ningún nivel de autocrítica o aprendizaje probablemente esté editando la realidad.
→ Cómo fue el caso real de Ecorise: qué tenían antes, qué se construyó y qué cambió en la operación
La trampa del precio más bajo
En Argentina el presupuesto siempre importa. Pero hay una diferencia entre ser cuidadoso con el presupuesto y elegir por precio.
El problema con elegir la propuesta más barata no es que sea barata. Es que casi siempre refleja una de estas tres situaciones: el alcance está subestimado, la calidad técnica va a ser inferior, o la propuesta va a crecer en el camino con adicionales que no estaban en el contrato original.
La propuesta más barata que termina con adicionales no contemplados suele ser la más cara al final del proyecto. Y la más cara que te pide firmar antes de entender el problema puede ser la más costosa de todas si resulta que lo que construyeron no resuelve lo que necesitabas.
El precio tiene que ser parte de la evaluación, pero no el criterio central. El criterio central es si esta agencia entiende el problema y tiene evidencia de haber resuelto problemas parecidos.
La trampa del plazo imposible
"Lo tenemos en dos meses" es otra señal de alerta, dependiendo del proyecto.
Los plazos en software tienen una dinámica conocida: la estimación inicial suele ser optimista porque en ese momento no se conoce el problema en profundidad. A medida que avanza el desarrollo y aparecen las complejidades reales, el plazo se estira. Eso no siempre es mala fe. A veces es simplemente que la estimación se hizo sin el diagnóstico suficiente.
El problema es cuando el plazo se promete como argumento de venta sin ningún análisis real detrás. Un plazo bien estimado tiene que venir con supuestos explícitos: qué asume el plazo en términos de alcance, qué no incluye, qué puede impactar la duración si aparecen cambios.
Si la única respuesta al "¿cómo estimaron ese plazo?" es "según nuestra experiencia", es una señal de que nadie se sentó a desagregar el alcance en serio.
Qué tiene que tener el contrato
No hace falta ser abogado para revisar un contrato de desarrollo. Hay puntos básicos que tienen que estar, y si no están, hay que pedirlos antes de firmar.
Titularidad del código. El código fuente y todos los activos del proyecto deben quedar en poder del cliente. Sin excepciones.
Alcance definido. El contrato tiene que describir qué se incluye en el proyecto, no solo en términos generales. Cuantos más detalles, menos espacio para interpretaciones que terminan en adicionales.
Política de cambios. Tiene que quedar claro cómo se gestionan los cambios de alcance: si generan un costo adicional, cómo se aprueban, qué proceso se sigue. Sin eso, cualquier cambio se convierte en un punto de conflicto.
Hitos y pagos. Los pagos tienen que estar atados a hitos verificables, no solo a fechas. "Se paga el 30% al inicio, 30% a los 30 días y 40% al finalizar" es peor que "se paga el 30% al inicio, 30% cuando el módulo X esté funcional y aprobado, y 40% con el sistema en producción y aceptado".
Soporte post-entrega. Qué pasa después de que el sistema se entrega. Cuánto tiempo de garantía existe, qué cubre y qué no. Si hay bugs después de la entrega, quién los resuelve y en qué plazo.
El perfil de agencia que funciona para una PyME
Una empresa grande puede contratar una consultora grande con un equipo dedicado, metodología certificada y un gerente de proyecto de planta. Eso no escala para una PyME, y tampoco necesita escalar.
Lo que funciona para una empresa mediana es algo diferente: una agencia chica o mediana donde el equipo que vendió el proyecto es el mismo equipo que lo construye, donde hay acceso directo a las personas técnicas, y donde el interlocutor entiende el negocio además del código.
La desventaja de las agencias grandes para proyectos de PyME es la misma de siempre: sos un cliente chico para ellos. El equipo senior que estuvo en la reunión inicial no es el que va a estar en el proyecto. El plazo de respuesta cuando hay un problema es el que le toca a tu categoría de cliente.
Una agencia más chica que haya trabajado con empresas de escala parecida a la tuya tiene más incentivos para que el proyecto salga bien, más agilidad para adaptarse a los cambios, y generalmente más disposición a construir una relación de largo plazo.
Una diferencia que no siempre se menciona: el proceso antes del proyecto
Hay agencias que empiezan a construir desde el primer día. Y hay agencias que antes de construir hacen el diagnóstico.
La diferencia no es solo filosófica. Tiene un impacto directo en el resultado.
Cuando una agencia arranca a construir sin diagnóstico está asumiendo que lo que el cliente describió en la primera reunión es el problema correcto. A veces lo es. Más seguido de lo que parece, no lo es. El cliente describe el síntoma. El diagnóstico identifica la causa.
Un proceso de diagnóstico bien hecho antes del desarrollo evita meses de trabajo sobre la solución equivocada. Identifica los procesos que realmente necesitan un sistema, los que pueden resolverse de otra manera, las integraciones que van a ser necesarias y las que no. Y define un alcance que tiene sentido antes de que se escriba una sola línea de código.
En Eje Z ese proceso tiene nombre: el Sprint de Arquitectura. Son dos semanas donde mapeamos cómo opera realmente la empresa, dónde están los cuellos de botella, qué tiene sentido construir, en qué tecnología y en qué orden. El resultado no es una propuesta de ventas. Es un documento técnico que podés llevar a cualquier proveedor.
Si estás evaluando agencias y querés tener ese mapa antes de comprometerte con un desarrollo, ese es el punto de partida.
¿Estás evaluando opciones y no tenés claro por dónde empezar? Contanos cómo opera tu empresa y vemos si tiene sentido hacer el diagnóstico primero. Escribinos por WhatsApp →