Sitios web SaaS de adentro hacia afuera: por qué los precios y la documentación van primero

Resumen

La mayoría de los consejos sobre sitios web SaaS comienzan con la página de inicio y dejan los precios, la documentación y las preguntas frecuentes como pensamientos posteriores, lo que hace que esas páginas terminen contradiciéndose entre sí. Este artículo aboga por construir de adentro hacia afuera: comienza con la página de precios y la documentación de la API, donde viven las restricciones reales del producto, y deriva todo lo demás a partir de ellas. Presenta un marco de seis pasos: recopilar restricciones, construir la página de precios como el esqueleto, tratar la documentación de la API como una superficie del producto, derivar la exhibición de funciones de los flujos de trabajo, cosechar las preguntas frecuentes de conversaciones reales y terminar con una verificación de coherencia. El enfoque está diseñado para agencias que necesitan un proceso repetible con diferentes clientes. También incluye advertencias sobre cuándo el marco es excesivo y cómo gestionar las expectativas del cliente.

La mayoría de los consejos sobre cómo construir sitios web SaaS están al revés. Te dicen que empieces por la página de inicio — el héroe, el titular, la captura de pantalla del producto — y que trates los precios, la documentación y las preguntas frecuentes como páginas que completas una vez que el diseño está aprobado. Luego, semanas después, estás conciliando la promesa del titular de "todo ilimitado" con los límites de uso reales de la página de precios, y la sección de funciones muestra con orgullo una función beta que la documentación de la API ni siquiera menciona. Ese orden funciona solo cuando el producto es lo suficientemente simple como para que no se necesite conciliación, lo cual rara vez es el caso. Lo que realmente funciona — especialmente cuando haces esto repetidamente para clientes completamente diferentes — es construir el sitio de adentro hacia afuera: comienza por las páginas más restringidas y menos glamorosas (precios y documentación de la API), y deja que generen la página de inicio, la exhibición de funciones y las preguntas frecuentes. Aquí tienes un marco de seis pasos para hacerlo, y en el camino señalaré dónde se vuelve incómodo, porque lo es.

Un mapa rápido de la diferencia, porque todo el argumento se basa en ello:

	Primero la página (lo más común)	Primero las restricciones (este marco)
Dónde empiezas	Héroe y visuales de la página de inicio	Página de precios y documentación de la API
Qué impulsa el texto	Historia de marca y diseño	Límites reales del producto y flujos de trabajo
Exhibición de funciones	Enumera todo lo que hace el producto	Sigue los caminos que toman los usuarios reales
Preguntas frecuentes	Escritas al final, a partir de suposiciones	Cosechadas del soporte y ventas
Resultado al lanzar	Afirmaciones inconsistentes, conflictos ocultos	Las páginas se leen como un solo producto

Paso 1 — Lee la página de precios antes de escribir una palabra.

Un cliente te entrega una lista de funciones, un deck de marca y un enlace de demostración, y te pide una página de inicio. Para el final de la primera llamada, ya estás discutiendo el texto del héroe y los esquemas de color. Intenta frenar eso. Pide la página de precios y los límites de los planes — incluso si son solo un Google Doc con notas — y verás que todo el proyecto cambia.

Estás buscando las restricciones duras: qué significa un asiento, cómo se cuenta el uso de datos, qué funciones existen en cada nivel de plan, si hay una API y qué puede hacer realmente. Estas restricciones son la verdad fundamental. Cada afirmación de marketing que hagas después tiene que sobrevivir al contacto con ellas.

Aquí tienes un escenario típico. El cliente es una herramienta de seguimiento de tiempo: plan Gratis, plan Pro, plan Empresa. El deck de ventas dice "escalable para cualquier equipo". La página Pro dice "proyectos ilimitados". Pero el equipo de soporte confirma que las cuentas Pro en realidad están limitadas a 10 proyectos activos por espacio de trabajo, y la documentación de la API dice que un proyecto puede tener como máximo 50 miembros. La página de inicio nunca se escribe hasta que alguien resuelve esto, porque "proyectos ilimitados" ahora es una cuestión legal, no una cuestión de texto. Si hubieras empezado con la página de inicio, habrías escrito "proyectos ilimitados" en el héroe y habrías descubierto el conflicto dos semanas después, cuando el diseño ya estaba aprobado. Empezar con las restricciones significa que el conflicto sale a la superficie en la primera semana, cuando arreglarlo no cuesta nada.

¿Qué deberías recopilar exactamente en este paso? Las definiciones de los planes y cualquier tabla comparativa de funciones por plan. La documentación de la API, o al menos una lista de lo que la API puede y no puede hacer. Las preguntas más comunes del equipo de soporte (más sobre esto en el Paso 5). El deck de ventas, con la advertencia de que los decks de ventas son donde vive la fantasía. Y el producto real, abierto para que puedas ver las páginas de configuración donde se aplican los límites — porque el producto mismo es la autoridad final. Una pantalla de configuración que dice "Máximo 10 proyectos" anula cualquier hoja de cálculo.

Este paso no produce un entregable. Produce una lista de hechos — límites, definiciones, excepciones — contra los que verificarás todas las demás páginas. Para una agencia, este es también el paso que separa el trabajo repetible de apagar incendios. Escribe las restricciones en un documento compartido y habrás construido la fuente de verdad que toda futura actualización de página referenciará.

Paso 2 — Construye la página de precios como el esqueleto de todo el sitio.

La página de precios no parece un lugar para empezar. Es una tabla con números y nombres de planes — la página menos glamorosa del sitio. Pero es el contrato del producto con el usuario, y es donde se decide la arquitectura de la información de todo el sitio. Si el trabajo del sitio es educar a un visitante hasta que esté listo para registrarse, la página de precios es donde converge esa educación. Cada función que importa para una decisión de compra se nombra allí; cada límite que importa se indica o se enlaza.

Toma la herramienta de seguimiento de tiempo. Tres planes: Gratis, Pro, Empresa. La tabla necesita columnas que reflejen cómo se segmenta realmente el producto — número de proyectos, integraciones, profundidad de informes. Para cada celda, necesitas el valor honesto, no el aspiracional. Si Pro incluye 10 proyectos activos, la celda dice 10 proyectos activos, con un enlace a las preguntas frecuentes de precios que explican qué significa "activo" y qué sucede cuando llegas al límite. Una de las decisiones más difíciles aquí es qué decir sobre el plan que más quieres que compren los visitantes. Muchas páginas de precios hacen obvio el plan ancla — resaltado, con una insignia de "Más popular" — y el texto que lo rodea explica por qué es el adecuado para este visitante. Para la herramienta de seguimiento de tiempo, Pro es el ancla: es donde comienzan las integraciones y la profundidad de informes, por lo que la página debería argumentar ese caso explícitamente en lugar de asumir que el visitante leerá la tabla y lo concluirá por sí mismo.

Aquí también es donde decides qué términos serán canónicos en todo el sitio. Si el producto llama a los grupos "espacios de trabajo" en la página de precios pero el texto de marketing dice "equipos", cada página posterior hereda la inconsistencia. Escribir la página de precios primero te obliga a elegir el vocabulario, y deberías elegir el que use el propio producto — porque el producto y la documentación tienen que coincidir con él, y el sitio de marketing es el que puede adaptarse.

Una página de precios también necesita su propio FAQ. Las preguntas que pertenecen allí son las que están ligadas a la mecánica específica de los planes: qué cuenta como asiento, qué sucede cuando cambias a un plan inferior, si la facturación es anual o mensual, qué significa "activo" para un proyecto. Hay un cuerpo de práctica bien desarrollado sobre cómo estructurar páginas de precios para la conversión, y vale la pena leer sobre la mecánica. Pero dentro de este marco, el trabajo de la página de precios no es solo convertir — es fijar las decisiones fácticas que todas las demás páginas obedecerán. Si quieres profundizar en la mecánica, esta guía para arreglar páginas de precios SaaS las cubre en detalle.

Paso 3 — Trata la documentación de la API como una superficie del producto, no como un manual.

Un desarrollador está evaluando la herramienta de seguimiento de tiempo. Su empresa necesita extraer automáticamente las hojas de horas en un sistema de nóminas. La documentación está organizada alfabéticamente por endpoint: /projects, /reports, /timesheets, /users. El desarrollador no tiene idea de con qué llamada empezar, y la sección de "Autenticación" asume conocimientos que no tiene — la documentación nunca explica que creas una clave de API en la página de configuración bajo "Integraciones". El desarrollador cierra la pestaña, convencido de que el producto no se integrará limpiamente. Sin embargo, toda la información necesaria estaba presente en la documentación; solo estaba organizada en el orden que usaría un manual de referencia, no en el orden que usaría un humano.

La documentación organizada por flujo de trabajo habría cambiado ese resultado: "Inicio rápido", "Autenticarse", "Extraer hojas de horas", "Crear un proyecto", "Webhooks y sincronización". Cada sección comienza con la tarea y luego muestra el endpoint. El inicio rápido podría tomar cinco minutos seguirlo y producir una llamada a la API exitosa — lo cual es el equivalente en documentación a una prueba gratuita. Para un producto orientado a desarrolladores, esta es la página más persuasiva del sitio.

Para cualquier SaaS que tenga una API, la documentación es una página de tu sitio web lo hayas planeado o no. El punto de referencia de la industria — establecido por gigantes como Stripe, GitHub y Twilio — es una documentación que se lee como un producto: explica la tarea que el desarrollador está tratando de hacer, no solo los endpoints disponibles. El principio es que la documentación de la API es parte de la experiencia del producto, y debería seguir la misma lógica de adentro hacia afuera que el resto del sitio: comienza con las tareas que el desarrollador puede lograr, luego revela la mecánica.

La ventaja para la agencia es que escribir documentación de esta manera saca a la superficie la lista de restricciones — lo que la API puede hacer realmente, dónde están los límites de tasa, qué endpoints faltan — y detectarás esos conflictos antes de que aparezcan en una página de marketing. Si la documentación de la API es una parte importante del sitio de este cliente, hay una guía más profunda para escribir documentación que los desarrolladores realmente usen.

Paso 4 — Deriva la exhibición de funciones de los flujos de trabajo, no de la lista de funciones.

El cliente te envía por correo una hoja de cálculo con 40 funciones y te pide una página de funciones. La respuesta fácil es una cuadrícula: 40 elementos, cada uno con un icono y un pie de foto. El resultado parece completo pero se lee como ruido, porque la cuadrícula no tiene historia. Nadie visita un sitio web SaaS para aprender cada función; visitan para saber si este producto hace el único trabajo para el que vinieron. Así que la exhibición debería construirse a partir de flujos de trabajo, no de la lista de funciones.

Trabaja el ejemplo. El camino ganador más común de la herramienta de seguimiento de tiempo, según el equipo de soporte del cliente, es un líder de equipo que se registra, invita a tres colegas, crea un proyecto y ejecuta un informe al final de la semana. Ese es el flujo de trabajo. La exhibición de funciones debería seguirlo: una sección sobre invitar a tu equipo (cubriendo asientos y roles), una sección sobre configurar un proyecto (cubriendo plantillas y configuraciones del proyecto), una sección sobre el panel de informes (cubriendo los gráficos y las opciones de exportación). Cada sección muestra una captura de pantalla de ese momento exacto en el producto, no una captura recortada de un panel de configuración raramente usado. El visitante ve su propio camino, y las funciones que ve en el camino son las que le importan.

El flujo de trabajo siguiente, para un visitante ligeramente diferente, es el ejecutivo que nunca usa la herramienta: aprueba hojas de horas y revisa el informe semanal. La exhibición puede agregar una sección para ese visitante al final — "Para gerentes" — sin romper la narrativa. Dos flujos de trabajo suelen ser suficientes para empezar; no necesitas uno por cada persona.

La advertencia — una real — es que una exhibición basada en flujos de trabajo requiere saber cuáles son los flujos de trabajo comunes. Eso requiere hablar con soporte y ventas, no solo con el gerente de producto. Si el cliente no puede decirte las tres formas principales en que la gente usa el producto, eso es lo primero a arreglar, porque el sitio web adivinará de lo contrario. Este paso a menudo revela que el producto no tiene un flujo de trabajo primario claro — lo cual es un problema del producto, no del sitio web. Señálalo honestamente; un sitio web no puede fabricar un flujo de trabajo que no existe. Para una forma sistemática de ordenar estos flujos de trabajo, esta pieza sobre estructurar una exhibición de funciones para conversiones recorre la secuencia de decisiones.

Paso 5 — Cosecha el FAQ del soporte y ventas, no de tu imaginación.

Tienes dos días antes de que el sitio se lance, y el FAQ todavía está vacío. El instinto es escribir diez preguntas en una tarde — generalmente las preguntas que te gustaría que el producto respondiera en lugar de las que los clientes reales hacen. Eso está al revés. El FAQ tiene un trabajo específico: eliminar las últimas dudas entre un visitante y un registro. Las páginas de FAQ efectivas, como las que ves de HubSpot, Slack y Zendesk, funcionan porque están organizadas alrededor de consultas reales, son buscables y concisas. Son el producto de escuchar, no de inventar.

El escenario realista: estás en la página de precios y sabes que el mayor obstáculo para la herramienta de seguimiento de tiempo es la integración: "¿Esto funciona con QuickBooks?" Una revisión del registro de soporte muestra que esa es la pregunta previa a la venta más común. Esa pregunta, con su respuesta, pertenece al FAQ de la página de precios. La segunda más común, de las llamadas de ventas, es "¿Qué pasa con mis hojas de horas si cancelo?" Eso también pertenece allí. Cada respuesta acorta el ciclo de ventas y reduce la carga de soporte, porque un visitante que ve la respuesta por escrito confía más en el producto que uno que tiene que preguntar.

La regla para la agencia: no escribas ni una sola respuesta al FAQ hasta que hayas mirado los tickets de soporte, las notas de las llamadas de ventas y los correos de incorporación. ¿Cuáles son las preguntas que realmente se repiten? Esas van. Todo lo demás va en la página de funciones o en ningún lado. Y a medida que el sitio se desarrolle, revisa el FAQ — cada nuevo cambio de precios o lanzamiento de función crea nuevas preguntas, y el FAQ es el lugar más barato para capturarlas.

También hay una razón para pensar en la estructura del FAQ, no solo en el contenido. Una lista larga y desplazable de preguntas es difícil de escanear; agrupar por categoría (Facturación, Integraciones, Gestión de cuenta) con una tabla de contenidos en la parte superior la hace realmente útil. La funcionalidad de búsqueda ayuda una vez que la lista crece más allá de cierto tamaño — esta es la parte de la página donde el diseño importa tanto como el texto, porque un FAQ no buscable es un FAQ no leído.

Una cosa más, que es la parte incómoda: el FAQ suele ser la página más honesta del sitio, porque es la página donde respondes la pregunta que el visitante tiene miedo de hacer. Si una pregunta se siente incómoda de responder — "¿Puedo realmente cancelar en cualquier momento?" "¿El plan gratuito muestra anuncios?" — esa sensación incómoda es evidencia de que pertenece allí, no una razón para eliminarla. El visitante tiene esa pregunta ya sea que la respondas o no; si no lo haces, inferirán una respuesta, y la respuesta que infieran será peor que la verdad.

Paso 6 — Unifica y haz control de calidad en cada página, antes de mostrárselo al cliente.

Estás a punto de mostrarle al cliente el sitio terminado. Antes de hacerlo, abre la página de precios y la página de funciones una al lado de la otra. Revisa cada nombre de función: ¿coinciden? Revisa cada número: ¿la página de precios dice "10 proyectos" y la página de funciones dice "hasta 10 proyectos" y la referencia de la API dice "máx. 10" — todos iguales? Revisa cada promesa: ¿está "proyectos ilimitados" en algún lugar del sitio, y si es así, es verdad? Luego busca el vocabulario propio del producto: ¿dice "espacios de trabajo" en todas partes, o se desliza a "equipos"? Aquí es donde detectas que la página de inicio dice "no se requiere tarjeta de crédito" mientras que el flujo de registro en realidad sí pide una tarjeta de crédito en la prueba gratuita — la clase exacta de inconsistencia que mata la confianza.

El beneficio del orden de adentro hacia afuera llega aquí. Como cada página se derivó de las mismas restricciones, el trabajo de coherencia es una pasada de verificación en lugar de una misión de rescate. Pero no lo omitas. Las contradicciones que sobreviven son las sutiles — una función llamada "aprobaciones" en la página de precios pero "flujos de revisión" en la documentación de la API, una captura de pantalla en la página de inicio que muestra un panel de modo oscuro que el producto no incluye, una afirmación de que el producto es "confiable para equipos remotos" que provino del deck de marca y no coincide con la lista real de clientes del cliente.

Una técnica práctica: convierte la lista de restricciones en el guion para la pasada de QA. Recorre cada página y verifica cada dato contra la lista. Esto funciona porque la lista de restricciones se escribió en la primera semana, antes de que existieran las páginas, por lo que es una fuente genuinamente independiente. Si comienzas el QA desde el diseño o desde la memoria, perderás los datos que cambiaron mientras construías.

En este punto, la razón para secuenciar el trabajo se vuelve obvia. Cuando las páginas se construyen en paralelo desde diferentes fuentes, esta pasada de QA encuentra conflictos cada vez, y cada conflicto significa retrabajo en una página que parecía terminada. Cuando las páginas se construyen en secuencia a partir de una sola lista de restricciones, la pasada de QA encuentra errores tipográficos. Esa es la diferencia entre un proceso repetible y una crisis constante. Para mantener todo el sitio contando una sola historia después del lanzamiento — nuevas funciones, nuevos equipos, nuevos redactores — necesitas una versión de mantenimiento de la misma disciplina, y un marco para unificar la historia de un sitio web SaaS entre páginas es el siguiente paso natural.

Las advertencias que mantienen esto honesto.

Tres cosas que este marco no afirma. Primero, para un SaaS muy temprano sin API, con un solo plan y un caso de uso obvio, el orden importa mucho menos; podrías construir ese sitio en cualquier orden y el trabajo de conciliación sería trivial. El marco se paga solo cuando hay complejidad real — múltiples planes, una API, muchas funciones, varias audiencias. No lo apliques como dogma a un producto que es esencialmente una página de aterrizaje con un botón de registro.

Segundo, construir de adentro hacia afuera produce un progreso visible lento al principio. El cliente pidió una página de inicio, y tú estás entregando una tabla de precios y un documento de restricciones. Te presionarán, porque la página de inicio es lo que pueden mostrar a los inversores y a su propio equipo. Gestionar esa expectativa — mostrándoles cómo las decisiones de la página de precios dan forma a todo lo demás — es parte del trabajo, no un fracaso del mismo. Una forma de mantener el impulso es producir un mockup tosco de la página de inicio temprano, claramente etiquetado como un contenedor que espera contenido, para que el cliente pueda ver el destino mientras construyes el esqueleto.

Tercero, la lista de restricciones cambia. Los precios cambian, las API crecen, los planes se multiplican. El marco asume que mantienes el documento de restricciones actualizado después del lanzamiento, porque el sitio web se deteriorará en el momento en que deje de reflejar los límites reales del producto. Este es el costo de mantenimiento del enfoque de adentro hacia afuera: la fuente de verdad solo es veraz si alguien es dueño de ella.

Conclusión.

El fallo más común en los proyectos de sitios web SaaS no es un texto débil o un mal diseño — son páginas que no están de acuerdo entre sí, porque se construyeron en el orden equivocado. Comienza con la página de precios y la documentación de la API, donde viven las restricciones reales del producto; deriva la exhibición de funciones de los flujos de trabajo reales; cosecha el FAQ de conversaciones reales; y termina con una pasada de coherencia que verifica en lugar de rescatar. Hazlo con algunos clientes diferentes y descubrirás que es menos un proceso creativo y más una línea de ensamblaje — lo cual, en una agencia, es exactamente lo que quieres. El trabajo creativo sigue ahí; solo se aplica donde tiene mayor apalancamiento.