El brief es el primer documento que decide si un proyecto sale bien. Un mal brief significa una estimación imprecisa, expectativas difusas, retrabajo sin fin y un sobrecoste del 30-50%. Un buen brief significa una estimación precisa (±15%), una visión compartida de la tarea y un resultado predecible.
El problema: el 70% de los clientes que nos llegan para un desarrollo no sabe qué poner en un brief. «Necesitamos una web» no es un brief. «Necesitamos una tienda online con 500 productos, integrada con Holded, con versión móvil y un presupuesto de hasta 22.000 €» sí lo es. En este artículo repasamos los 12 apartados que debe tener todo brief, con ejemplos de formulaciones buenas y malas.
Para qué sirve un brief
Un brief no es burocracia. Es una herramienta que ahorra dinero y tiempo a las dos partes: al cliente y al equipo de desarrollo.
Qué le aporta un brief al cliente
— Una estimación precisa. El proveedor calcula a partir de requisitos concretos en lugar de adivinar. El margen de la estimación es de ±15% en vez de ±50%.
— Propuestas comparables. Cuando 3-5 proveedores estiman el mismo brief, puedes comparar precios y enfoques de forma objetiva.
— Expectativas por escrito. «¡Pero si habíamos quedado en esto!». El brief es la constancia escrita de lo acordado.
— Menos retrabajo. El 80% de los conflictos con proveedores nace de expectativas que no coinciden. Un brief reduce ese riesgo en un 70%.
Qué le aporta un brief al proveedor
— Entender la tarea antes de empezar (no a mitad de proyecto)
— Una base para la especificación de requisitos
— Una forma de estimar el plazo y el coste
— Datos para planificar el equipo
El brief no es el documento final. No sustituye a la especificación. El brief dice «qué queremos»; la especificación, «cómo lo vamos a construir». El cliente escribe el brief y el proveedor redacta la especificación a partir de él. Más sobre especificaciones en un artículo aparte.
Los 12 apartados de un brief
Apartado 1: sobre la empresa
Quién eres, a qué se dedica tu empresa, qué productos o servicios ofrece. No es una formalidad: el proveedor necesita contexto.
Mal: «Somos una empresa».
Bien: «Fabricante de muebles, B2B y B2C, 15 años en el mercado, 3 showrooms en Madrid, más de 2000 referencias, facturación de 6,3 millones de euros al año. La web actual funciona con WooCommerce, 10K visitas al mes».
Apartado 2: objetivo del proyecto
¿Para qué necesitas la web o la app? ¿Qué problema de negocio resuelves?
Mal: «Necesitamos una web nueva».
Bien: «El objetivo es que las ventas online pasen de 135.000 € a 405.000 € al mes. La web actual no convierte: tarda 6 segundos en cargar, no está adaptada al móvil y el carrito está anticuado. Necesitamos una tienda online nueva centrada en la conversión y en el tráfico móvil».
La clave. El objetivo siempre es una métrica de negocio, no una tecnología. No «hacerlo en React», sino «subir la conversión del 1% al 2,5%». La tecnología la elegirá el proveedor: conocer los stacks es su trabajo.
Apartado 3: público objetivo
¿Quién va a usar el producto? Edad, roles, tareas, problemas.
Mal: «Todo el mundo».
Bien: «1) Compradores particulares: mujeres de 28-45 años, renta media y media-alta, que compran muebles para su casa. 2) Interioristas: compran por volumen y necesitan una tarifa B2B con acceso privado. 3) Clientes corporativos: compran para oficinas y necesitan la documentación de compras».
Apartado 4: tipo de proyecto
¿Qué necesitas exactamente: una web, una app, un sistema, un bot?
— Landing page (1-5 páginas)
— Web corporativa (10-30 páginas)
— Tienda online
— Aplicación web (SaaS, CRM, ERP)
— App móvil (iOS, Android, multiplataforma)
— Chatbot / Telegram Mini App
— Portal / marketplace
— Rediseño o migración de un proyecto existente
Apartado 5: requisitos funcionales
El apartado más importante. ¿Qué tiene que hacer el producto? Enumera todas las funciones, agrupadas por rol o por módulo.
Mal: «Una tienda online normal con todo lo necesario».
Bien:
«Catálogo: 2000 productos, 5 niveles de categorías, filtros por facetas (talla, color, material, precio), búsqueda con autocompletado.
Ficha de producto: fotos (4+ ángulos, zoom), características (tabla), reseñas, “se suelen comprar juntos”.
Carrito: añadir al carrito sin iniciar sesión, códigos promocionales, cálculo de los gastos de envío.
Pago: Stripe (tarjetas, Apple Pay, Google Pay), Bizum y pago contra factura para clientes empresa.
Envíos: integración con SEUR y Correos Express + repartidores propios.
Área de cliente: historial de pedidos, seguimiento, devoluciones.
Sección B2B: acceso con cuenta de empresa, precios mayoristas, extractos de cuenta».
¿No tienes claro qué funciones necesitas? Escribe historias de usuario: «Como [rol], quiero [acción] para [resultado]». Ejemplo: «Como comprador, quiero filtrar los productos por talla para encontrar rápido uno que me valga». Con 20-30 historias de usuario tienes un brief completo.
Apartado 6: integraciones
¿Con qué tiene que funcionar el producto?
— Programa de contabilidad/ERP (Holded, A3, Sage, SAP Business One: ¿cuál y qué versión?)
— CRM (HubSpot, Pipedrive, Salesforce)
— Pagos (Redsys, Stripe, PayPal, Bizum o la pasarela de tu banco)
— Envíos (Correos, SEUR, MRW, DHL, DPD, reparto propio)
— Analítica (Google Analytics 4)
— Email/SMS (Mailchimp, Klaviyo, Twilio)
— Marketplaces (Amazon, eBay, El Corte Inglés: sincronización de stock)
— Centralita (Aircall, RingCentral)
Apartado 7: diseño
¿Qué esperas del diseño?
— ¿Tienes manual de marca o guía de estilo?
— Ejemplos de webs que te gustan (y por qué)
— Ejemplos que no te gustan (y por qué)
— ¿Necesitas un diseño desde cero o un rediseño del actual?
— Móvil: ¿responsive o mobile-first?
Mal: «Bonito y con estilo».
Bien: «Minimalista, como Muji.com. Mucho espacio en blanco, fotos de producto grandes y protagonismo de la tipografía. No nos gustan las interfaces recargadas de una típica gran superficie de electrónica. Adjuntamos el manual de marca».
Apartado 8: contenido
¿Quién va a preparar el contenido (textos, fotos, vídeo)?
— Textos: el cliente / el redactor del proveedor / hace falta contenido SEO
— Fotos de producto: las tenemos en alta calidad / hace falta una sesión de fotos
— Vídeo: lo tenemos / hace falta producirlo
— Catálogo: ¿quién sube los 2000 productos?
Una trampa habitual. El desarrollo está terminado, la web está lista, pero el contenido no. El lanzamiento se retrasa 1-3 meses. Mete la preparación del contenido en el plan del proyecto desde el primer día.
Apartado 9: requisitos de SEO
— ¿Necesitas optimización SEO?
— ¿Qué palabras clave importan?
— ¿Hay posiciones actuales que debas conservar en el rediseño?
— ¿Necesitas datos estructurados (Schema.org)?
— ¿Varios idiomas (versiones regionales)?
Apartado 10: restricciones técnicas
— Preferencias tecnológicas (si las hay)
— Hosting: en la nube (¿cuál?), servidor dedicado, el hosting del proveedor
— Requisitos de seguridad (RGPD, certificaciones)
— Carga prevista (visitas al día, transacciones por minuto)
— Requisitos de SLA (tiempo de inactividad aceptable)
Apartado 11: presupuesto y plazos
Sí, di tu presupuesto. No te deja en una posición débil para negociar; te ahorra tiempo.
Mal: «El presupuesto ya lo hablaremos. Dinos tu precio».
Bien: «Presupuesto: 13.000-22.000 €. Plazo: lanzamiento antes del 1 de septiembre de 2026. Podemos subir hasta 32.000 € si hay un buen motivo».
Sin presupuesto, un proveedor te ofrecerá o el mínimo (y no tendrás lo que querías) o el máximo (y pagarás de más). Lo que mejor funciona es una horquilla de presupuesto.
Apartado 12: criterios de éxito
¿Cómo sabrás que el proyecto ha salido bien? Métricas concretas y medibles.
— Conversión de la web > 2,5%
— Tiempo de carga < 2 segundos (Core Web Vitals en verde)
— 100% adaptada al móvil
— Integración con el ERP: el stock se sincroniza en < 5 minutos
— Tráfico orgánico > 50K al mes a los 6 meses
Ejemplos de formulaciones buenas y malas
Checklist antes de enviar el brief
Revisa tu brief antes de enviárselo a los proveedores:
— El objetivo del proyecto está descrito (una métrica de negocio, no «hacer una web»)
— El público objetivo está descrito (quién, para qué, en qué contexto)
— Están todas las funciones (o escritas como historias de usuario)
— Las integraciones nombran sistemas y versiones concretos
— Hay ejemplos de diseño (me gusta / no me gusta)
— El presupuesto está indicado (una horquilla)
— El plazo está indicado (la fecha objetivo)
— El plan de contenido está descrito (quién lo prepara y cuándo)
— Hay criterios de éxito (medibles)
— El documento está estructurado y se lee bien (no es un muro de texto)
Envía el brief a 3-5 proveedores. Compara no solo los precios, también las preguntas que hacen. Un buen proveedor hace 10-20 preguntas para aclarar dudas. El que da un precio al momento sin una sola pregunta o no ha leído el brief o piensa «ya lo añadiremos todo después».
Brief y especificación: en qué se diferencian
Se confunden constantemente. La diferencia es de fondo:
El proceso: brief → estimación → elección de proveedor → especificación → desarrollo. El brief es la puerta de entrada. La especificación es el documento de trabajo.
Errores habituales en los briefs
Error 1: un brief demasiado vago
«Necesitamos una web para vender nuestros productos». Eso no es un brief, es una petición. Un proveedor no puede estimar un proyecto sin detalles. El resultado es o una estimación inflada (por si acaso) o una a la baja (seguida de extras).
Error 2: requisitos técnicos en lugar de objetivos de negocio
«Hacedlo con Next.js, PostgreSQL y Redis». El stack lo decide el proveedor. Tú describes el problema y él propone la solución. Quizá WordPress encaje mejor con tu tarea que Next.js. O al revés.
Error 3: ocultar el presupuesto
«El presupuesto lo hablamos cuando nos mandéis la estimación». Resultado: el proveedor no sabe a qué horquilla apuntar. Te propone una solución de 90.000 € cuando tu presupuesto es de 13.000 €. O al revés: recorta la solución hasta 9.000 € cuando estabas dispuesto a gastar 32.000 €. Las dos partes pierden el tiempo.
Error 4: «Hacedlo como [competidor]»
No sabes cuánto gastó tu competidor en el desarrollo (lo más probable, entre 5 y 10 veces tu presupuesto). Usa a la competencia como referencia de diseño y funciones, no como especificación.
Error 5: no fijar prioridades
50 funciones, todas igual de importantes. El proveedor no sabe qué construir primero. Divídelas en Must Have (sin esto no podemos lanzar), Should Have (importante, pero no crítico) y Nice to Have (si sobran recursos). Es el método MoSCoW.
Preguntas frecuentes sobre el brief de desarrollo
¿Cuánto se tarda en redactar un brief?
2-4 horas para un proyecto sencillo (una landing page, una web pequeña). 1-2 días para uno complejo (una tienda online, una app, un sistema). El tiempo compensa: un buen brief ahorra semanas de idas y venidas y meses de retrabajo.
¿Puede el proveedor ayudarme a redactar el brief?
Sí. Muchos proveedores hacen una sesión de briefing gratuita (o de pago): una reunión de 1-2 horas en la que te ayudan a ordenar tus requisitos. Es una práctica normal, así que no dudes en pedirla.
¿Tengo que indicar un presupuesto?
No es obligatorio, pero es muy recomendable. Lo mejor es una horquilla de presupuesto (desde-hasta). El proveedor te propondrá una solución que encaje en ella en lugar de algo desorbitado.
¿Y si no sé qué funciones necesito?
Empieza por los escenarios de uso: describe cómo usará el cliente el producto. «El cliente entra en la web → busca un producto → lo añade al carrito → paga → recibe un aviso». El proveedor convertirá los escenarios en funciones.
¿Todos los proyectos necesitan un brief?
Para proyectos de más de unos 2.700 €, sí. Para pequeños ajustes (añadir una página, cambiar un botón) basta un email que describa la tarea. Cuanto más grande es el proyecto, más importa el brief.
¿Puedo cambiar el brief después de enviarlo?
Con total libertad, hasta que se firma el contrato. Una vez empezado el desarrollo, los cambios pasan por una solicitud de cambio. Cada cambio en los requisitos después del arranque supone tiempo y dinero extra. Por eso compensa dedicarle tiempo al brief antes de empezar.
¿Cuál es el mejor formato para un brief?
Google Docs o Word: fáciles de comentar y editar. Notion: para datos estructurados. PDF: para la versión final. Excel: solo para tablas (tarifas, una matriz de funciones). No uses una presentación (PowerPoint): el texto importa más que lo visual.
