¿Mandaste tres presupuestos para tu MVP y los tres te dijeron que pueden hacerlo, en el mismo tiempo y por precios completamente distintos? Ahí empieza el problema.
No es que alguno esté mintiendo necesariamente. Es que probablemente ninguno leyó el mismo documento. Uno cotizó lo que vos pediste. Otro cotizó lo que interpretó. Y el tercero cotizó lo que sabe hacer. Y vos quedás en el medio tratando de comparar números que no comparan nada.
Evaluar una agencia o estudio de desarrollo no es googlear "mejores agencias MVP Argentina" y quedarte con la que tiene mejor sitio web. Es saber qué preguntar y, sobre todo, qué te tiene que preocupar cuando algo no cierra.
El diagnóstico inicial dice todo
El primer momento que te revela cómo trabaja alguien es la primera reunión. No lo que dicen de sí mismos — eso lo ensayaron. Lo que hacen con tu problema.
Una señal de alerta: si en la primera reunión ya te están cotizando pantallas y tecnologías, cerrá la notebook. No porque estén apurados, sino porque todavía no saben qué problema estás tratando de resolver. Un estudio de producto serio arranca con preguntas incómodas: ¿quién va a usar esto primero? ¿Qué tiene que pasar para que una persona vuelva la semana siguiente? ¿Qué necesitás probar antes de pedir más plata?
Pensemos en un founder que llega con una app de gestión para clínicas veterinarias. Tiene mapeadas 35 pantallas, flujos para tres tipos de usuario y una app nativa para iOS y Android. Un estudio que solo ejecuta arranca a cotizar esas 35 pantallas. Un estudio de producto le pregunta: ¿cuál de esos tres usuarios es el que tiene que convencer primero para que el negocio funcione? Probablemente la respuesta cambia el alcance a la mitad.
Eso es lo que distingue el diagnóstico real del diagnóstico de cortesía.
Cómo proponen el alcance del MVP
El segundo momento crítico es cómo te presentan el alcance. Y acá hay una trampa clásica: el alcance que parece razonable pero no fue discutido.
Si te mandan una propuesta con un listado de funcionalidades sin haberte preguntado cuáles son las más importantes, lo que están haciendo es cotizar todo lo que dijiste en la reunión, no lo que necesitás para validar. La diferencia puede ser de meses y miles de dólares.
Preguntá esto: ¿qué sacarían del alcance si el presupuesto baja un 30%? La respuesta te dice mucho. Si te dicen "nada, todo es esencial", o si se ponen nerviosos, desconfiá. Un equipo que entiende tu producto sabe al instante qué es el núcleo y qué es un nice-to-have. Y te lo dice sin que lo presiones.
Otro punto que se ignora seguido: ¿el precio es fijo o por hora? La diferencia no es solo financiera. Con precio por hora, el riesgo de que el proyecto se alargue es tuyo. Con precio cerrado, el riesgo es del estudio. No es lo mismo firmar "vamos a hacer esto por X" que firmar "vamos a facturarte lo que tarde".
Y la fecha: ¿está comprometida por escrito? No "calculamos que en tres meses", sino una fecha concreta en el contrato. Si no hay fecha, no hay compromiso real.
Qué pasa después del lanzamiento
Este es el momento que casi nadie pregunta antes de firmar, y suele ser donde todo se complica.
Lanzaste. Tiene usuarios. Algo no funciona como esperabas. ¿Qué pasa? ¿Podés entrar al código? ¿Está en tu repositorio o en el de ellos? ¿Podés contratar a otro equipo para seguir si la relación no funciona?
El código debería ser tuyo desde el día uno. No al final del proyecto, no "cuando saldás el último pago". Desde el primer commit. Si un estudio no puede garantizarte eso, estás firmando una dependencia que no termina cuando termina el proyecto.
También importa cómo manejan los cambios después de lanzar. Los primeros usuarios siempre te van a pedir cosas que no estaban en el plan. ¿Hay un proceso claro para evaluar si esos cambios van o no van? ¿O cada pedido es una negociación nueva?
Un equipo que diseña y construye tiene esta conversación antes de que surja el problema. Uno que solo codifica te la deja para cuando ya es urgente.
El lugar del diseño en todo esto
Hay algo que separa a un estudio de producto de una agencia de desarrollo: si el diseño viene antes del código o después.
Cuando el diseño se hace antes — cuando hay decisiones de UX que se toman mirando el problema del usuario, no solo los wireframes que pediste — el producto llega al lanzamiento con muchas menos sorpresas. Las pantallas tienen sentido entre sí. Los flujos no rotan tres veces en desarrollo porque nadie preguntó cómo funciona la autenticación.
Cuando el diseño se hace "mientras" o directamente no existe, el producto se lanza y el feedback de los primeros usuarios te hace rediseñar el 40% de lo que ya está construido. Que es el peor momento para hacerlo.
La pregunta que ordena todo
Antes de firmar con cualquier estudio, preguntá esto: ¿qué tiene que salir bien en las primeras dos semanas para que este proyecto sea exitoso?
Si te responden con un listado de tareas técnicas, estás hablando con un equipo de ejecución. Si te responden con una hipótesis sobre el usuario, estás hablando con un equipo de producto.
No hay una respuesta mala per se — depende de lo que necesitás. Pero si lo que buscás es alguien que te ayude a pensar el producto y no solo a construirlo, sabés cuál te conviene.
Los criterios no cambian mucho si estás en Buenos Aires, en Santiago o en cualquier otro lado. Lo que cambia es cuánto tardás en descubrirlos si no los preguntás desde el principio.