Cómo redactar un brief técnico para un proyecto web o de app, 2026

Qué incluye un brief técnico

Un brief técnico para un proyecto web o de app es un documento breve que le dice a un equipo qué problema quieres resolver, para quién, dentro de qué límites y cómo vas a juzgar el resultado. Bien escrito, permite que el equipo estime con honestidad. Mal escrito, te trae presupuestos que no se pueden comparar.

Esta guía es para fundadores y responsables de producto que están a punto de hablar con un estudio o un equipo de ingeniería. Recorre cada parte del brief, lo que conviene dejar fuera y una comprobación breve antes de enviarlo.

Un brief no es una especificación

Un brief fija el problema, el alcance, las restricciones y las métricas de éxito. Una especificación describe cómo se comporta cada pantalla y cada endpoint. La especificación llega después, normalmente redactada junto con el equipo una vez acordado el brief.

Mantenlo corto. Una guía de una agencia sobre briefs de software (fechada en agosto de 2026) lo sitúa entre dos y cuatro páginas para la mayoría de los proyectos pequeños y medianos, y señala que un documento de requisitos de cincuenta páginas sugiere que el diseño se hizo antes de que los ingenieros opinaran. Adjunta por separado maquetas, informes de ejemplo y exportaciones, cada uno con una nota de una línea que explique por qué está ahí.

Empieza por el problema, los usuarios y las métricas de éxito

Abre con el problema, no con la lista de funciones. La misma guía recomienda describirlo en términos observables: con qué frecuencia ocurre, cuánto tarda, quién participa y cuánto cuesta cuando sale mal. "Nuestro proceso es ineficiente" no le da nada que dimensionar a un equipo. "El personal vuelve a teclear cada pedido a mano, unas cuarenta veces por semana, y algunos se registran dos veces" sí. (Esa frase ilustra el estilo; no es una cifra de un cliente real.)

Nombra a los usuarios y lo que puede hacer cada uno

Enumera cada tipo de usuario, cuántos hay aproximadamente de cada uno y qué puede ver, crear o aprobar. Clientes, personal y administradores suelen necesitar permisos distintos, y los permisos son de las primeras cosas que cambian el tamaño de un desarrollo.

Escribe métricas de éxito que puedas comprobar después del lanzamiento

Elige resultados verificables: una tasa de errores, un tiempo de carga, una tasa de finalización, un objetivo de adopción. "Mejor experiencia de usuario" no se puede comprobar. "Tasa de finalización del pago que reporta tu analítica, medida frente al trimestre anterior" sí. Una segunda guía sobre briefs de desarrollo de software (publicada en abril de 2026) incluye los resultados de negocio medibles, los criterios de rendimiento y los estándares de calidad como la sección final de un brief completo.

Alcance: imprescindible, después y no ahora

Ordena las funciones en tres grupos: necesarias para el lanzamiento, deseadas poco después y fuera del alcance de esta versión. Una prueba útil para el primer grupo: si la función faltara el día del lanzamiento, ¿retrasarías el lanzamiento? Si no, pertenece al segundo grupo.

Da a cada función una definición de terminado

Los nombres cortos de funciones esconden grandes diferencias. La guía de abril de 2026 pone el ejemplo del "registro de usuarios", que puede significar un alta solo con correo o un inicio de sesión con varios proveedores y verificación por teléfono. Son cantidades de trabajo muy distintas. Una línea de criterios de aceptación lo resuelve, por ejemplo: "Un visitante puede crear una cuenta con un correo y una contraseña, y recibe un correo de confirmación."

La misma guía señala que los equipos tienden a presupuestar la lectura razonable más estrecha de un brief vago, y que la distancia entre la intención y esa lectura aparece más tarde en forma de solicitudes de cambio.

Etiqueta las ideas como ideas

Si una función es una corazonada y no una necesidad, dilo. Las funciones candidatas marcadas como ideas permiten que el equipo valore el núcleo y ofrezca opciones, en lugar de valorarlo todo como un compromiso.

Describe las integraciones con precisión

Para cada sistema al que debe conectarse el producto, indica el sistema, los datos que se mueven, la dirección y si es aceptable la sincronización en tiempo real o por lotes. Pagos, correo, un CRM, un sistema de inventario y un proveedor de inicio de sesión ya existente son habituales. Las integraciones suelen ser lo más difícil de estimar en un proyecto, así que la vaguedad aquí es lo que más cuesta.

Objetivos de rendimiento y accesibilidad

Los requisitos no funcionales describen qué tan bien debe funcionar el producto, no qué hace. Dos de ellos son fáciles de escribir al principio y caros de añadir después.

Rendimiento. web.dev define un presupuesto de rendimiento como "un conjunto de límites impuestos a las métricas que afectan al rendimiento del sitio", como el peso de la página, el número de solicitudes, el First Contentful Paint y el Time to Interactive, y aconseja fijarlo pronto porque hacerlo pronto ayuda a evitar volver atrás más tarde. La página se actualizó por última vez en noviembre de 2018, así que trata sus líneas base de ejemplo (Time to Interactive por debajo de 5 s en 3G, menos de 170 KB de recursos de la ruta crítica) como una muestra del formato y no como objetivos actuales. En tu brief, indica la métrica, la clase de dispositivo y la red que te importan.

Accesibilidad. La Iniciativa de Accesibilidad Web del W3C afirma que es "más eficiente y eficaz incorporar la accesibilidad desde el principio de los proyectos" y recomienda evaluarla pronto y durante todo el desarrollo (página actualizada el 3 de febrero de 2026). También señala que WCAG 2.2 se publica como ISO/IEC 40500. El paso práctico es nombrar una versión y un nivel en el brief, como "WCAG 2.2 nivel AA". Nuestra guía sobre los requisitos de WCAG 2.2 para aplicaciones web explica qué significa eso en la implementación.

Otras restricciones. Añade los navegadores y dispositivos compatibles, el número previsto de usuarios, los requisitos de alojamiento o de residencia de datos, las obligaciones de cumplimiento que apliquen a tu sector y quién mantendrá el código después del lanzamiento. Si debes conservar un sistema existente o usar una pila concreta, dilo y da el motivo.

Presupuesto, plazos y quién decide

Comparte un rango de presupuesto

Da un rango y márcalo como firme o exploratorio. Las dos guías coinciden: un rango funciona como un límite compartido del alcance y no como un ancla, y ocultarlo produce propuestas con precios muy distintos que son difíciles de comparar. Si aún no tienes uno, lee primero cuánto cuesta un sitio web o cuánto cuesta una app de iOS.

Indica la fecha y el motivo

Una fecha con motivo es una restricción: una feria, la renovación de un contrato, una normativa que entra en vigor. Una fecha sin motivo es una preferencia, y un equipo puede intercambiarla por alcance. Di cuál es la tuya y describe cómo sería una primera versión mínima viable si el alcance completo no cabe.

Nombra a quien decide

Indica quién aprueba el alcance, quién da el visto bueno a cada fase, quién desempata y quién responde las dudas del día a día. La falta de un responsable de decisiones es una causa habitual de retrasos. Si quieres ver cómo avanza normalmente un proyecto acotado desde el brief hasta la entrega, lee cómo trabajamos.

Qué dejar fuera

• Decisiones tecnológicas sin fundamento. Indica el requisito, no la pila, salvo que exista una restricción real. Si tienes un motivo, da el motivo.
• Diseños de pantalla y estructuras de bases de datos. Llegan después de que los ingenieros opinen.
• Listas de funciones copiadas de la competencia. Señala un flujo que te guste y explica por qué funciona.
• Historia de la empresa y declaraciones de misión. Bastan dos o tres frases sobre a qué se dedica el negocio y cómo gana dinero.

Revisa el brief antes de enviarlo

• El problema va antes que cualquier función.
• Cada tipo de usuario figura en la lista, con lo que puede hacer.
• Las funciones están ordenadas en lanzamiento, poco después y no ahora, cada una con su definición de terminado.
• Cada integración indica el sistema, los datos y la dirección.
• Los objetivos de rendimiento y accesibilidad están escritos como números o como un estándar con nombre.
• El presupuesto es un rango, la fecha tiene un motivo y se nombra a quien decide.
• Las métricas de éxito se pueden comprobar después del lanzamiento.

Conclusión

Un buen brief técnico es breve, concreto y honesto sobre lo que aún se desconoce. Plantea el problema antes que la solución, ordena el alcance por prioridad y le da al equipo las restricciones que cambian el precio. Si estás planeando un proyecto de desarrollo web y quieres una segunda opinión sobre un borrador, envíanoslo.

Preguntas frecuentes

¿Qué extensión debe tener un brief técnico?

Entre dos y cuatro páginas bastan para la mayoría de los proyectos pequeños y medianos. Un documento muy largo suele indicar que las decisiones de diseño se tomaron antes de que opinaran los ingenieros. Pon las maquetas y los datos de ejemplo en anexos, con una nota de una línea en cada uno.

¿Debo indicar la pila tecnológica en el brief?

Solo si hay una restricción real, como un sistema que debes conservar o un equipo interno que mantendrá el código. Si no, indica el requisito, por ejemplo "iniciar sesión con correo y con Apple", y deja que el equipo proponga la pila. Si tienes una preferencia, explica por qué.

¿Tengo que compartir mi presupuesto?

Comparte un rango y márcalo como firme o exploratorio. Sin él, las propuestas llegan con precios muy distintos y es difícil compararlas.

¿Y si todavía no conozco los detalles técnicos?

Describe el problema, los usuarios y los resultados en lenguaje claro y marca las dudas como abiertas. Un brief que dice lo que no sabes es más útil que uno que adivina.

¿Qué diferencia hay entre un brief y una especificación completa?

Un brief fija el problema, el alcance, las restricciones y las métricas de éxito para que un equipo pueda estimar. Una especificación describe cómo se comporta cada pantalla y cada endpoint, y normalmente se redacta con el equipo una vez acordado el brief.