¿Estás por firmar con una agencia para tu MVP y no sabés si lo que te prometieron es realista, o solo lo que querías escuchar?
Es una pregunta válida. Y tiene trampa: casi todas las agencias te van a decir que sí a todo en la primera reunión. La diferencia aparece tres meses después, cuando el proyecto está en pausa, el presupuesto se agotó y el producto todavía no llegó a un usuario real.
Lo que no dice el presupuesto
El número que te mandan en la primera propuesta no te dice gran cosa por sí solo. Te dice cuánto van a cobrar. No te dice cuándo vas a tener algo funcionando, quién va a tomar las decisiones de producto cuando algo no entre en el scope, ni qué pasa si el plazo se corre.
Pensemos en un founder que llega con una idea de marketplace para servicios de hogar —algo acotado, flujo claro. Le cotizan tres opciones: una agencia grande a 40 mil dólares con seis meses de plazo, un freelance a 8 mil sin fecha de entrega, y un estudio mediano a precio cerrado con una fecha específica. La pregunta no es cuál es más barato. La pregunta es cuál te da algo para mostrarle a un usuario en ocho semanas.
Ese es el criterio que importa cuando estás lanzando tu primera versión.
Agencia genérica vs. estudio de producto
Hay una diferencia real entre una agencia que hace desarrollo y un equipo que trabaja con foco en producto. No es marketing: cambia cómo se toman las decisiones.
Una agencia genérica ejecuta lo que le pedís. Si el scope está mal definido —y en un MVP casi siempre lo está— te cobran por cada cambio, o te entregan exactamente lo que pediste aunque no sirva para validar nada.
Un estudio de producto te va a frenar antes de arrancar. Va a preguntarte qué querés probar, quién es el usuario que va a usar esto la primera semana, y cuál es el flujo mínimo que necesitás para saberlo. Eso a veces incomoda. Pero es la diferencia entre gastar en construir y gastar en aprender algo útil.
Antes de firmar, fijate si quien te cotiza tiene esa conversación o te manda el presupuesto directo.
Las preguntas que hacen la diferencia
Hay tres áreas que vale la pena revisar antes de cerrar cualquier acuerdo.
El ownership del código. ¿Desde el primer día el repositorio es tuyo? Suena obvio, pero no siempre lo es. Algunos estudios trabajan en repos propios y te entregan el código al final. Si algo sale mal en el camino —o si simplemente querés cambiar de equipo después— te quedás sin acceso a nada. El código debería estar en tu GitHub desde el día uno.
Las decisiones de stack. ¿Te explican por qué eligen las tecnologías que eligen, o te dicen "usamos esto porque es lo mejor"? No hace falta que seas desarrollador para entender si la explicación tiene lógica. Lo que sí tenés que saber es si están eligiendo por tu proyecto o por lo que ya saben hacer ellos.
El ritmo de entrega. ¿Cómo vas a ver el avance? Una demo semanal es un estándar razonable. Si la respuesta es "te mandamos actualizaciones por mail" o "al final del mes hacemos una revisión", es una señal de alerta. Los proyectos que no tienen puntos de control frecuentes se desvían solos.
Por qué el precio más bajo casi nunca es la variable
No es que el precio no importe —importa, especialmente cuando el presupuesto es acotado. El problema es cuando se convierte en el único criterio.
El presupuesto más bajo casi siempre viene con alguna de estas tres condiciones: sin fecha de entrega, cotización por hora que crece con cada cambio, o un freelance solo que tiene otros proyectos en paralelo. Cualquiera de las tres te puede costar más caro que haber pagado un poco más desde el arranque.
Lo que sí conviene buscar es precio cerrado con fecha por escrito. Que sepas desde el día uno cuánto gastás y cuándo tenés algo funcionando. Eso te permite planificar: cuándo podés salir a buscar usuarios, cuándo tenés algo para mostrarle a un inversor, cuándo podés decidir si seguir construyendo o pivotar.
Qué pasa con las promesas de velocidad
Hay una promesa que circula mucho: "dos semanas y tenés tu MVP". A veces es real. A veces es una forma de cerrar el deal rápido y después estirar los plazos.
La diferencia está en qué entra en esas dos semanas. Un MVP de dos semanas tiene que ser un flujo concreto y funcional —no treinta pantallas, no tres tipos de usuario, no un panel de reportes. Si la cotización de dos semanas incluye todo eso, o no te están entendiendo, o te están vendiendo algo que no van a poder cumplir.
Una buena señal: que el equipo te ayude a achicar el scope antes de arrancar. Que te pregunten qué se puede sacar, no solo qué querés meter.
Cómo trabaja Cambalache
En Cambalache trabajamos con precio cerrado y fecha de entrega por escrito antes de arrancar. El código está en el GitHub del cliente desde el primer día, hacemos una demo todos los viernes, y si no llegamos a la fecha acordada, seguimos sin costo adicional.
No revendemos herramientas ni plataformas no-code como si fueran desarrollo a medida. Cada proyecto lo construimos según lo que necesita ese producto: el stack lo elegimos en función del caso, no de lo que nos resulta más cómodo.
Nuestros planes de MVP —Validate, Launch y Scale— tienen precios fijos y plazos definidos. La propuesta con alcance, precio y fecha la mandamos en 24 horas después de la primera reunión. No porque sea un trámite, sino porque es la forma de que puedas decidir con información real, no con promesas.