Plantilla de brief de desarrollo web para founders

Un build de sitio web se tuerce cuando el kickoff es un Loom, un moodboard de Figma y la esperanza de que todos compartan la misma definición de «done». Los founders lo sienten primero. Estás pagando por un sitio que debería ganar leads, explicar el producto o cerrar una ronda de funding, y en cambio obtienes pulido infinito en las páginas equivocadas.

Un brief de desarrollo web es el documento corto que lo corrige. Declara qué estás construyendo, para quién, qué está dentro y fuera de alcance, quién es dueño de qué cuentas y cómo aceptarás el trabajo. Esta guía te da una plantilla de brief lista para copiar más la razón de cada bloque, para que puedas briefear a un freelancer, una agencia o un builder in-house sin redescubrir los mismos huecos a mitad del sprint.

Por qué un brief supera una llamada vaga de kickoff

Las llamadas de kickoff sirven para tono y confianza. Son terribles como única fuente de verdad. La gente recuerda oraciones distintas. Los hilos de Slack entierran la única decisión que importaba. Tres semanas después alguien pregunta si el SEO del blog estaba incluido, y nadie puede señalar una respuesta escrita.

Un brief fuerza las preguntas difíciles temprano, cuando cambiar de dirección es barato. También protege al builder. El alcance claro es cómo los buenos freelancers cotizan con honestidad y cómo comparas cotizaciones sin teatro de manzanas con naranjas.

Un brief en portapapeles se sienta entre una llamada de kickoff y un calendario de build para que las decisiones queden escritas.

Idea clave: Si una decisión no está en el brief o en una enmienda a él, trátala como no decidida. Esa sola regla previene la mayoría de las peleas de «pensé que habíamos acordado».

Objetivos y cómo sabrás que el sitio funcionó

Empieza con outcomes, no con conteo de páginas. «Necesitamos un sitio de marketing» es una categoría. «Necesitamos solicitudes de demo calificadas de compradores SaaS Series A en EE. UU. y la UE» es un objetivo. Escribe dos o tres objetivos como máximo. Más que eso suele significar que estás mezclando un sitio de marca, una app de producto y un motor de contenido en un deseo vago.

Para cada objetivo, añade una señal de éxito que puedas observar en los primeros 30 a 90 días tras el lanzamiento. Ejemplos que funcionan en un brief:

• Completaciones del formulario de demo por semana (baseline vs rango objetivo)
• Tiempo hasta la primera página útil para un visitante nuevo (home a pricing o docs)
• Impresiones orgánicas para un cluster definido de frases una vez conectado Search Console
• Tickets de soporte que dejan de llegar porque una FAQ o página de docs ahora los responde

No pongas «rankear #1 por nuestra keyword de categoría» como señal de éxito a menos que ya tengas un plan de contenido y enlaces. Los rankings son el outcome de muchos sistemas. Un brief puede fijar expectativas de SEO (ver más adelante). No debería prometer posiciones.

Los objetivos se sientan por encima de las listas de páginas. Cada objetivo se liga a una señal que puedes chequear tras el lanzamiento.

Audiencia, jobs primarios y objeciones

La mayoría de los briefs omiten la audiencia o pegan un persona de un pitch deck. Los builders necesitan algo más afilado. ¿Quién llega, qué job intenta terminar y qué los haría irse?

Escribe como máximo tres notas cortas de audiencia. Para cada una, responde:

1. ¿Qué acabaron de buscar, hacer clic o de dónde fueron referidos?
2. ¿Qué decisión intentan tomar en esta visita?
3. ¿Qué prueba reduciría el riesgo (logos de clientes, claridad de precios, página de seguridad, historia del founder)?

Si vendes a buyers y users, di qué sitio es para quién. Un sitio de producto de founder que intenta convertir end users y CFOs en el mismo homepage suele diluir a ambos.

Cada nota de audiencia empareja un job-to-be-done con la prueba que reduce el bounce.

Sitemap, páginas y flujos críticos

Aquí es donde los proyectos vagos se vuelven shippable. Lista las páginas que necesitas en v1, luego los flujos que deben funcionar de extremo a extremo. Una lista de páginas sin flujos es cómo los formularios de contacto se envían rotos y cómo «book a demo» se vuelve un mailto que nadie probó en móvil.

Forma sugerida para el brief:

• Páginas must-ship. Home, producto o servicios, pricing (o cómo vendes), about, contacto o demo, páginas legales que realmente necesitas.
• Should-ship si el presupuesto lo permite. Case studies, índice del blog, careers, integraciones, página de status.
• Explícitamente después. Cualquier cosa que te tiente inventar a mitad del build (portal de clientes, sitio completo de docs, foro comunitario).

Luego lista los flujos como paths numerados, no como features:

1. Visitante aterriza en home → pricing → formulario de demo → thank-you page → notificación por email a ventas.
2. Visitante aterriza en una página de servicio → case study relacionado → contacto.
3. Visitante recurrente golpea una URL vieja → redirección al nuevo path (stub del mapa de redirecciones).

Si ya tienes un sitio en vivo, adjunta el inventario actual de URLs y marca keep / merge / kill. Los rediseños que ignoran el mapa viejo de URLs crean daño de SEO y bookmarks que se ve como «el sitio nuevo mató el tráfico» cuando el brief nunca pidió redirecciones.

Las cajas de páginas y las flechas de flujo pertenecen a la misma sección para que «done» incluya el path, no solo el layout.

Expectativas de SEO que vale la pena escribir

Los founders a menudo dicen «necesitamos SEO» como dicen «necesitamos branding». Los builders oyen un programa completo de contenido o higiene técnica básica. Pon la expectativa en el brief para que las cotizaciones coincidan con la realidad.

Un bloque práctico de SEO para el build de un sitio de marketing suele cubrir:

• Baseline técnico. HTTPS, estructura sensata de URLs, XML sitemap, robots.txt que no bloquee páginas de dinero, canonicals en plantillas primarias, HTML rastreable para el contenido principal.
• On-page para plantillas acordadas. Titles y H1s únicos, meta descriptions que puedas editar después, enlaces internos entre hubs y páginas de dinero.
• Analytics y Search Console. Quién crea las properties, de quién es la cuenta de Google que las posee, y que el builder obtiene acceso solo según se necesite.
• Producción de contenido. Di si el lanzamiento incluye N artículos, migración de posts viejos, o ninguno. «Haremos el blog después» está bien cuando está escrito.
• Redirecciones. Requeridas al reemplazar un dominio existente o una estructura de paths.

Lo que el bloque de SEO no debe hacer es garantizar rankings, tráfico o una posición fija para una fecha. La propia guía de Google sobre crear contenido útil trata de utilidad y confianza, no de promesas de vendor. Tu brief puede exigir un sitio rastreable y claro. No puede comprar un slot en el SERP.

Baseline técnico, plantillas on-page, ownership de Search Console y redirecciones se sientan en una sección SEO honesta.

Error frecuente: Pedir «SEO completo» sin presupuesto de contenido y sin mapa de redirecciones, y luego culpar al tema cuando el orgánico cae tras un rediseño.

Hitos, revisiones y decision owners

Los hitos convierten un brief en un calendario en torno al cual la gente puede planificar. Mantenlos pocos y concretos. Una forma típica de sitio de marketing:

1. Brief locked. Tú y el builder firman el alcance, páginas, expectativas SEO y out of scope.
2. Estructura y wireframes. Arquitectura de información y plantillas clave acordadas antes del pulido visual.
3. Diseño de plantillas primarias. Home más una página interior de dinero antes de diseñar cada página.
4. Build y content drop. Copy y assets llegan en una fecha declarada o el timeline se desliza por definición.
5. Staging review. QA funcional y de contenido contra la lista de aceptación.
6. Launch y handoff. DNS, analytics, acceso al repo y documentación según lo definido en ownership.

Nombra un decision owner para diseño, copy y go-live técnico. Los comités que todos «aprueban» y nadie decide quemarán tu timeline. Si eres el founder, escribe tu propio nombre para la llamada final de marca y messaging, y nombra quién puede aprobar bugs de staging día a día.

Cada hito tiene una ventana de fecha y un owner nombrado para la llamada que desbloquea el siguiente paso.

Ownership de cuentas, dominios y código

Esta sección salva relaciones. Antes de que alguien empiece, escribe quién es dueño de:

• Registrador de dominio y DNS
• Cuenta de hosting o plataforma (Vercel, Netlify, Cloudflare Pages, WP Engine, etc.)
• Repositorio Git
• CMS (si hay)
• Google Analytics / GA4 y Google Search Console
• Envío de email para formularios (Resend, Formspree, tu ESP)
• Scripts de terceros (chat, ads, herramientas A/B)
• Archivos de diseño (Figma)

Regla default que funciona para la mayoría de founders: la empresa es dueña de cada cuenta de producción. El builder recibe acceso de colaborador invitado, no ownership personal del dominio o el repo. Si un freelancer insiste en retener el dominio «hasta el pago final», eso es una bandera de negociación, no una práctica estándar.

También escribe qué pasa en el handoff: invites de admin transferidas, cuentas personales del builder removidas, deploy keys rotadas si hace falta, y un README corto de cómo enviar un cambio.

Cuentas de la empresa con acceso del builder, no keys de producción del builder.

Advertencia: No dejes Search Console o el dominio bajo el Gmail personal de un contratista tras el lanzamiento. Cuando esa relación termina, la recuperación se pone fea.

Out of scope (la sección que protege a todos)

Out of scope no es hostilidad. Es cómo mantienes la cotización honesta. Lista el trabajo que no estás comprando en este engagement, aunque suene relacionado.

Ítems comunes para un brief de sitio de marketing:

• App web custom o UI de producto con login
• Redacción continua de contenido más allá de un conteo acordado de artículos
• Link building u outreach
• Setup y gestión de ads pagados
• Identidad de marca desde cero (logo, guidelines completas) a menos que esté cotizado
• Producción de fotografía o video
• Expansión multilingüe más allá de los locales listados
• Migraciones de listas de email, pipelines de CRM o sistemas de billing
• Uptime con SLA más allá del default del host

Si algo podría aparecer después, ponlo bajo «candidatos de fase 2» en lugar de colarlo en v1 de palabra. Los builders que asienten a un alcance infinito o subentregarán o enviarán change orders. Los founders que se niegan a escribir out of scope suelen descubrirlo como facturas sorpresa.

Los ítems out of scope se sientan fuera de la cerca de v1 para que las cotizaciones sean comparables y los change orders intencionales.

Criterios de aceptación que dicen cuándo el sitio está done

La aceptación es la checklist que usas en staging antes de que el DNS cambie. Sin ella, «done» se vuelve gusto. Con ella, el gusto sigue importando para el diseño, pero los issues que bloquean el ship son objetivos.

Escribe la aceptación como declaraciones pass/fail ligadas al brief:

• Cada página must-ship es alcanzable desde la navegación primaria o un path de sitemap acordado.
• Cada flujo listado se completa en desktop y un teléfono mid-size (el formulario envía, thank-you se muestra, la notificación llega).
• Las redirecciones del mapa acordado retornan el destino correcto.
• Titles y H1s existen para plantillas primarias y coinciden con el copy deck acordado.
• Analytics dispara en los eventos clave que listaste (submit de formulario, clic outbound a calendario).
• Las páginas legales enlazadas en el footer están presentes si tu mercado lo requiere.
• Enlaces rotos y errores de consola en plantillas primarias están limpios o explícitamente waived.
• El acceso a repo, hosting y analytics coincide con la sección de ownership.

El pulido de diseño puede tener una lista separada de «follow-ups conocidos». No mantengas el lanzamiento rehén de debates de píxeles que nunca estuvieron en el brief, y no saltes flujos rotos porque el homepage se ve bien.

Las líneas de aceptación pass/fail convierten la revisión de staging en una decisión de ship en lugar de un argumento de gusto.

Escenario trabajado para un founder B2B SaaS briefando v1

Maya dirige una herramienta de workflow Series A. Necesita un sitio público antes de un anuncio de partner en seis semanas. Está tentada a pedir «un sitio moderno como Linear, más un blog, más un teaser de portal de clientes».

Llena el brief en cambio:

• Objetivos. Historia de producto lista para partners; solicitudes de demo de leads de ops mid-market; Search Console conectado con redirecciones de los paths viejos de Webflow.
• Audiencia. Ops managers evaluando herramientas este trimestre; partners chequeando credibilidad de integración.
• Páginas must-ship. Home, product, integrations, pricing, security, about, demo, privacy, terms. Índice del blog con solo tres posts migrados.
• Flujos. Formulario de demo a HubSpot; página de security enlazada desde footer y footnote de pricing.
• SEO. Baseline técnico, redirecciones de 14 URLs viejas, sin retainer de contenido nuevo en v1.
• Out of scope. UI de portal de clientes, pack de ilustraciones custom, ads, producción continua de blog.
• Ownership. Cloudflare y GitHub de la empresa; builder como colaborador; Maya es dueña de GA4 y Search Console.
• Aceptación. Flujos testeados en staging; spot-checks de redirecciones; el formulario aterriza en el pipeline correcto de HubSpot.

La cotización que obtiene es comparable entre dos freelancers porque ambos están pricing la misma cerca. Cuando alguien sugiere un mock de portal en la semana tres, ella señala out of scope y agenda fase 2 en lugar de volar la fecha del partner.

El brief de Maya cerca páginas listas para partners y redirecciones, y aparca el portal en fase 2.

Plantilla copy-paste de brief de desarrollo web

Usa esto como doc de trabajo. Borra la guía entre paréntesis mientras llenas las respuestas.

1. Snapshot del proyecto

• Título de trabajo / nombre de la empresa:
• Dominio primario (actual e intencionado):
• Ventana objetivo de lanzamiento:
• Decision owner (llamada final de alcance y go-live):
• Contacto day-to-day:

2. Objetivos y señales de éxito

• Objetivo 1 + cómo lo mediremos en 30-90 días:
• Objetivo 2 + cómo lo mediremos:
• Objetivo 3 (opcional):
• Lo que este sitio no está destinado a resolver:

3. Audiencia y jobs

Para hasta tres audiencias:

• Quiénes son:
• Job en esta visita:
• Prueba que reduce el riesgo:
• CTA primario que queremos de ellos:

4. Marca y restricciones

• Assets de marca existentes (logo, colores, fonts, Figma):
• Notas de tono (tres adjetivos máximo, más un «evitar»):
• Competidores o sitios de referencia (qué tomar estructuralmente, no copiar):
• Notas de accesibilidad o compliance (target WCAG, industrias, regiones):
• Idiomas / locales en v1:

5. Sitemap y flujos

• Páginas must-ship:
• Should-ship si el presupuesto lo permite:
• Explícitamente después / fase 2:
• Flujos críticos (numerados):
• ¿Inventario de URLs existentes adjunto? (sí/no + enlace):
• Owner del mapa de redirecciones:

6. Contenido y assets

• Quién escribe el copy:
• Fecha de freeze de copy para plantillas de lanzamiento:
• Fuentes de imagen / video:
• Quotes de clientes o logos aprobados para uso:
• Páginas legales requeridas:

7. SEO y medición

• ¿Baseline de SEO técnico requerido? (sí/no)
• On-page para qué plantillas:
• Blog / contenido en v1 (conteo o ninguno):
• ¿Redirecciones requeridas? (sí/no)
• Herramientas de analytics y lista de eventos:
• Owners de cuentas de Search Console y analytics:

8. Preferencias de stack (opcional)

• Framework o CMS preferido (o «el builder recomienda»):
• Preferencia de hosting:
• Destino de formulario / CRM:
• Cosas que ya pagamos y deben reutilizarse:

9. Hitos

Hito	Ventana objetivo	Owner	Criterios de salida
Brief locked
IA / wireframes
Diseño de plantillas primarias
Build + content drop
Staging acceptance
Launch + handoff

10. Ownership

Asset	Cuenta owner de la empresa	Nivel de acceso del builder	Nota de handoff
Domain / DNS
Hosting
Git repo
CMS
Analytics
Search Console
Forms / ESP
Design files

11. Out of scope

• Lista ítems no incluidos en esta cotización:
• Candidatos de fase 2 (opcional):

12. Criterios de aceptación

• Checklist de declaraciones pass/fail para staging:
• Follow-ups conocidos permitidos tras el lanzamiento (non-blocking):
• Nombres de sign-off y fecha:

13. Notas comerciales (mantener cortas)

• Fixed fee o time-and-materials:
• Qué dispara un change order:
• Ventana de soporte tras el lanzamiento (días de bugfix, si hay):

Esa es la plantilla usable. Todo lo de arriba existe para que llenes estos campos con intención en lugar de headings vacíos.

Entregar el brief sin perder el hilo

Envía el brief antes de pedir una cotización final. Recórrelo una vez en vivo si el builder es nuevo para ti, luego congela una versión (fecha en el filename o historial de versiones de un doc compartido). Los cambios tras el freeze se vuelven enmiendas. Suena formal para un sitio de cinco páginas. Es cómo evitas pagar dos veces por la misma semana de trabajo.

Cuando compares vendors, puntúalos contra el mismo brief. Pregunta dónde discrepan de tu out of scope o tu bloque SEO. El desacuerdo temprano es útil. El silencio que se convierte en «el SEO estaba implícito» después no lo es.

Tras el lanzamiento, archiva el brief con el README de handoff. El siguiente contratista no debería necesitar una sesión espiritista con tu historial de Slack.

Una versión fechada del brief se mueve del founder al builder antes de la cotización final, luego se archiva con notas de handoff.

Preguntas frecuentes

¿Qué tan largo debe ser un brief de desarrollo web?

Dos a cinco páginas bastan para la mayoría de sitios de marketing. Si necesitas una novela, probablemente estás especificando una aplicación de producto. Mantén el brief corto y adjunta inventarios (URLs, redirecciones, copy decks) en lugar de meter cada fila en la narrativa.

¿Puedo usar este brief para Webflow, WordPress y código custom?

Sí. El brief es stack-agnóstico a propósito. Pon preferencias en la sección de stack si las tienes. Si no, pide al builder que recomiende un stack que coincida con tus necesidades de ownership y actualización, luego escribe esa elección de vuelta en el brief antes de que empiece el build.

¿Qué pasa si aún no conozco mi sitemap?

Dilo, y haz del discovery un hito pagado con una salida clara: un sitemap y flujos propuestos que apruebas antes del diseño visual. No finjas certeza que no tienes. Los sitemaps falsos crean rework.

¿Deben SEO y desarrollo ser briefs separados?

Para un sitio de marketing pequeño, un brief con un bloque SEO honesto suele ser mejor. Si estás comprando un programa grande de contenido, remediación de SEO técnico o trabajo internacional de hreflang, esos pueden ser statements of work separados enlazados desde este brief para que el ownership se mantenga claro.

¿Quién debe escribir el brief, founder o agencia?

El founder (o la persona dueña de los outcomes) debe escribir objetivos, audiencia, out of scope y ownership. Un buen builder puede ayudar a refinar sitemap, flujos y lenguaje de aceptación. Si una agencia escribe el brief entero sola, léelo como su documento de ventas hasta que edites los objetivos con tus propias palabras.

¿Qué pertenece a un change order?

Cualquier cosa que añada páginas, flujos, integraciones, locales o volumen de contenido más allá del brief locked, o que mueva un ítem de fase 2 a v1. Los tweaks de gusto dentro de una plantilla aprobada por lo general no. Si no estás seguro, pregunta «¿esto cambia la checklist de aceptación?» Si sí, es una conversación de change order.

Cierra el loop antes de comprar horas

Un brief claro no hará fuerte a un builder débil. Hará más rápidos a los builders fuertes, cotizaciones comparables y el día de lanzamiento aburrido en las formas que quieres. Llena la plantilla, congela una versión y trata las enmiendas como normales cuando el negocio aprende algo nuevo.

Si quieres ayuda para convertir un brief rough en un build acotado de sitio de marketing (páginas, baseline SEO, ownership y aceptación incluidos), contacta vía el formulario.