"¿Cuánto cuesta una app?" es como preguntar "¿cuánto cuesta una casa?". La respuesta honesta es: depende. De cuántas recámaras, en qué zona, con qué acabados, si ya tienes el terreno. Por eso, cuando pides una cotización de software con una descripción de dos líneas, recibes precios que van de lo muy barato a lo carísimo, y ninguno es comparable.
La solución es un brief: un documento breve que describe tu proyecto con la información que un desarrollador necesita para entenderlo y cotizarlo bien. En este artículo te explicamos qué incluir y te dejamos una plantilla.
¿Por qué vale la pena escribirlo?
- Cotizaciones comparables: todos los proveedores cotizan sobre la misma base.
- Precios más precisos: menos "colchón" por incertidumbre, menos sorpresas después.
- Ordena tus ideas: muchas veces, al escribirlo, descubres qué es realmente indispensable.
- Alinea a tu equipo: socios y áreas involucradas se ponen de acuerdo antes de invertir.
- Detecta buenos proveedores: los mejores harán preguntas inteligentes sobre tu brief; los menos serios cotizarán sin leerlo.
Un brief no tiene que ser largo ni técnico. Dos a cinco páginas escritas en lenguaje de negocio son suficientes para la mayoría de los proyectos.
Plantilla: las 10 secciones de un buen brief
1. Sobre tu empresa
Quiénes son, a qué se dedican, tamaño aproximado y mercado. Dos o tres párrafos bastan.
2. El problema
Describe la situación actual y qué está fallando, sin hablar todavía de la solución.
"Recibimos alrededor de 60 pedidos diarios por WhatsApp y correo. Tres personas los capturan en una hoja de cálculo y luego otra vez en el sistema de facturación. Cada semana hay pedidos duplicados o con cantidades erróneas."
Si puedes, agrega números: horas perdidas, errores, ventas que se escapan. Te servirán también para calcular el retorno de inversión.
3. Objetivos
¿Qué quieres lograr y cómo sabrás que funcionó? Que sean medibles:
- Reducir el tiempo de captura de pedidos en un 70%.
- Que el 50% de los clientes haga pedidos por su cuenta en seis meses.
- Eliminar los errores de doble captura.
4. Usuarios
¿Quién usará el sistema? Para cada tipo de usuario, qué necesita hacer:
| Usuario | Qué necesita hacer |
|---|---|
| Cliente mayorista | Ver su catálogo y precios, hacer pedidos, descargar facturas |
| Vendedor | Ver pedidos de sus clientes, aplicar descuentos autorizados |
| Almacén | Ver pedidos por surtir y marcarlos como enviados |
| Administración | Reportes de ventas y cobranza |
5. Funciones principales
Lista lo que el sistema debe hacer, ordenado por prioridad. Una técnica útil es clasificar cada función como:
- Indispensable: sin esto, el proyecto no tiene sentido.
- Importante: debería estar, pero podría esperar a una segunda etapa.
- Deseable: sería bueno tenerlo algún día.
Esta clasificación permite a los proveedores proponer una primera versión ajustada a tu presupuesto, como explicamos en ¿Qué es un MVP?.
6. Sistemas e integraciones
¿Con qué debe conectarse? ERP, CRM, sistema de facturación, pasarela de pagos, WhatsApp, tienda online, hojas de cálculo existentes. Menciona el nombre de cada herramienta y si sabes que tiene API.
7. Datos existentes
¿Hay información que migrar? Catálogos, clientes, historial de pedidos. ¿En qué formato está y qué tan "limpia" es? La migración de datos es una de las partes que más se subestiman.
8. Plataformas y requisitos especiales
- ¿Web, app móvil o ambas? (Te ayuda nuestra guía de apps nativas, híbridas y PWA.)
- ¿Varios idiomas o monedas?
- ¿Requisitos de seguridad o normativos en tu sector?
- ¿Debe funcionar sin conexión?
- ¿Cuántos usuarios simultáneos esperas?
9. Referencias y diseño
Sitios o apps que te gustan (y por qué), tu identidad de marca, y si ya tienes diseños o bocetos. Las referencias ayudan mucho a entender expectativas.
10. Presupuesto, tiempos y criterios de decisión
- Rango de presupuesto. Muchos dueños de negocio prefieren no compartirlo, pero un rango permite a los proveedores proponer la mejor solución posible dentro de él, en lugar de adivinar.
- Fecha deseada y si hay una fecha límite real (un evento, una temporada).
- Cómo vas a elegir: precio, experiencia, tiempos, soporte posterior.
- Persona de contacto que tomará las decisiones.
Lo que no debe llevar un brief
- Especificaciones técnicas que no dominas. "Debe usar tal lenguaje o tal base de datos" sólo si hay una razón real. Deja que los expertos propongan.
- Diseños de cada pantalla. Si los tienes, compártelos como referencia, pero el diseño detallado es parte del proyecto.
- Todo como "urgente" e "indispensable". Si todo es prioridad, nada lo es.
Después del brief
- Envíalo a 2 o 4 proveedores, no a veinte.
- Agenda una llamada con cada uno para resolver dudas. Observa qué preguntan.
- Pide propuestas por etapas, con lo que incluye y no incluye cada una.
- Compara con los criterios de nuestra guía para contratar a un desarrollador de software.
- Actualiza el brief con lo que aprendas en esas conversaciones: se convertirá en la base del alcance del proyecto.
En un proyecto ágil, las funciones del brief se convierten en el backlog inicial, que se irá ajustando con cada entrega.
Conclusión
Un buen brief no requiere conocimientos técnicos, sino claridad sobre tu negocio: qué problema tienes, quién lo sufre, qué quieres lograr y qué es indispensable. Una o dos tardes dedicadas a escribirlo te ahorran semanas de malentendidos y te ayudan a elegir al proveedor correcto.
En Dev jetzt revisamos tu brief sin costo, te ayudamos a completarlo con las preguntas que falten y te damos una propuesta clara por etapas. Escríbenos y cuéntanos tu proyecto, aunque todavía sea sólo una idea.