Pedís presupuesto para el mismo MVP a dos estudios distintos y te llegan números que difieren en miles de dólares. No es que uno te quiera cobrar de más: es que cada uno completó a su manera los huecos que dejaste sin definir. Ese documento que cierra los huecos antes de cotizar es el brief — y de lo bien que lo escribas depende el precio final, el plazo y cuántas sorpresas aparecen a mitad de camino.
Un brief flojo produce lo contrario: presupuestos inflados "por las dudas", malentendidos y features que aparecen a mitad del build.
Por qué el brief define tu presupuesto
Cuando una agencia recibe un brief vago, cotiza el peor escenario. No es mala fe: es la única forma de protegerse de lo que no está definido. Un brief claro reduce esa incertidumbre, y esa reducción se traduce directo en un presupuesto más ajustado y plazos más realistas.
Dicho de otra forma: el tiempo que invertís en el brief se lo ahorrás a tu billetera.
Checklist del brief
No hace falta que sea largo. Hace falta que sea claro. Estas son las secciones que pedimos:
1. El problema
- ¿Qué problema concreto resuelve el producto?
- ¿Quién lo tiene? (usuario específico, no "todos")
- ¿Cómo lo resuelven hoy sin tu producto?
2. El objetivo
- ¿Cómo se ve el éxito en 6 meses? (más ventas, ahorro de horas, mejor retención)
- ¿Qué métrica te diría que funcionó?
3. El alcance del MVP
- Las 3 a 5 funcionalidades imprescindibles para la primera versión
- Lo que explícitamente queda afuera de la primera versión (tan importante como lo que entra)
- Los tipos de usuario y qué puede hacer cada uno
4. Referencias
- Productos que te gustan y por qué
- Competidores directos
- Capturas, Figmas o links que ilustren lo que tenés en la cabeza
5. Restricciones reales
- Fecha límite (y qué la genera: una ronda, un evento, una temporada)
- Presupuesto disponible
- Integraciones obligatorias (medios de pago, sistemas que ya usás, APIs)
6. Lo que ya tenés
- Marca, identidad visual, dominio
- Contenido, base de datos, usuarios existentes
- Documentación o trabajo previo
El error más caro: no definir lo que queda afuera
La sección que más gente se saltea es "lo que queda afuera del MVP". Y es la más valiosa. Un MVP es, por definición, un recorte. Si no decidís qué no va en la primera versión, todo parece prioritario y el proyecto se infla hasta que no sale nunca.
Mejor un producto pulido que cubre el 20% del problema y sale, que uno que intenta el 80% y se atrasa seis meses. Definí el corte en el brief.
Cuánto detalle es suficiente
No necesitás wireframes ni especificaciones técnicas — para eso está el equipo. Necesitás claridad sobre el problema, el usuario y el recorte. Con eso, un buen equipo de producto te devuelve el resto: arquitectura, diseño, estimación.
Si tu idea todavía no pasó por validación, primero mirá cómo validar tu idea antes del MVP — el brief se escribe mucho mejor cuando ya tenés señales de demanda.
Antes de escribir una línea de código
El brief no es el documento que se firma y se congela: es el filtro final antes de que el equipo toque una sola línea de código. Mientras tenga huecos, cualquier estimación es una apuesta. Una vez que el problema, el usuario y el recorte están claros, el equipo arranca con una estimación real en vez de un número inflado "por las dudas".
Eso no significa que el brief quede inamovible: a medida que el proyecto avanza y aparecen datos reales de uso, las prioridades se ajustan. Pero el punto de partida tiene que estar firme antes del kickoff — y esas primeras dos semanas con foco son las que después rinden el triple durante todo el desarrollo.