Qué necesitas para hacer tu web a medida

«Necesito una web a medida, pero no sé qué tengo que pedir». Si te reconoces en esa frase, ya tienes un punto de partida. Es normal conocer bien tu negocio y, aun así, no saber si necesitas una tienda, un área privada, una herramienta de reservas o una combinación de varias cosas.

Antes de hablar de pantallas y presupuestos, conviene ordenar la necesidad. Esta guía te ayudará a distinguir lo que merece la pena preparar de lo que se puede decidir durante el proyecto. No es una lista de requisitos técnicos para rellenar a solas: es una forma de llegar a la primera conversación con preguntas mejores.

Antes de empezar: no necesitas tenerlo todo decidido

Imagina que gestionas actividades y recibes las reservas por teléfono, mensajes y una hoja de cálculo. Unas veces se duplica una plaza; otras, el cliente pregunta por una fecha que ya está completa. No hace falta saber cómo se programa un calendario para explicar ese problema. Basta con poder contar qué ocurre hoy, qué te gustaría que ocurriera y quién interviene.

Para iniciar el proyecto, intenta responder a estas tres preguntas:

• ¿Qué está fallando o qué oportunidad quieres aprovechar? Puede ser tiempo perdido, consultas que no llegan, información difícil de encontrar o ventas que requieren demasiados pasos.
• ¿Qué debería poder hacer alguien en la nueva web? Por ejemplo, comprobar disponibilidad y reservar sin tener que esperar una respuesta manual.
• ¿Cómo resolvéis eso ahora? Mostrar el proceso actual, incluso si parece improvisado, permite descubrir excepciones y tareas que una descripción idealizada suele esconder.

Con esas respuestas se puede empezar a definir el alcance. Después habrá decisiones compartidas: qué funciones son imprescindibles para la primera versión, qué información se necesita, cómo será el recorrido del usuario y qué conviene dejar para más adelante. Es razonable que aún no sepas cuál será la herramienta concreta, dónde se alojará o cómo se organizará internamente el sistema. Elegir eso forma parte del trabajo técnico.

También ayuda despejar un malentendido: «a medida» no significa programar cada pieza desde cero. Si una herramienta existente resuelve bien una parte, puede aprovecharse. Lo específico se desarrolla donde el funcionamiento de tu negocio lo exige. Cuando una web necesita funciones que una solución estándar no resuelve, ese análisis pertenece al desarrollo web a medida.

Así que, si todavía no tienes un documento perfecto, no pasa nada. Trae un caso real: «una persona nos pide una reserva, comprobamos las plazas, confirmamos por correo y después actualizamos una hoja». Esa pequeña historia explica más que una lista de tecnologías y nos da una base concreta para decidir qué debe hacer la web.

Define qué debe conseguir la web

Es habitual empezar un encargo enumerando páginas: «Inicio, quiénes somos, servicios y contacto». Esa lista puede ser útil más adelante, pero todavía no explica para qué servirá la web. Dos empresas pueden tener esas mismas cuatro páginas y necesitar experiencias completamente distintas.

Prueba a completar esta frase: «La web debe permitir que [alguien] pueda [hacer algo] para [conseguir un resultado]». Por ejemplo: «Una persona que organiza un viaje debe poder encontrar una actividad adecuada, comprobar cuándo se celebra y llegar a la reserva». Ya no estamos hablando de un menú; estamos describiendo una necesidad que se puede diseñar y comprobar.

La diferencia se ve en Cadizfornia Tours. El trabajo no consistía solo en publicar una bonita relación de rutas por Cádiz. Cada experiencia necesitaba explicar qué iba a vivir el viajero y conectarlo con su proceso de reserva. Por eso el proyecto incluyó una web pública y herramientas para gestionar esas reservas, que han evolucionado con la actividad. El objetivo de negocio daba sentido a las páginas y a las funciones.

Tu objetivo puede ser otro: recibir solicitudes bien informadas, vender productos, facilitar documentación a clientes o evitar que una persona copie datos de un sistema a otro. Conviene elegir un objetivo principal y anotar los secundarios. Si todo tiene la misma prioridad, resulta difícil decidir qué debe aparecer primero, qué recorrido merece más atención o qué funciones pueden esperar.

También ayuda describir qué pasa después del primer clic. «Quiero más contactos» es un comienzo, pero deja preguntas abiertas: ¿qué necesita saber alguien antes de escribir?, ¿qué datos hacen falta para responderle?, ¿quién recibe la solicitud?, ¿cuánto tiempo puede esperar? Esas respuestas cambian el formulario, el contenido y el modo de atenderlo. Una web útil no termina cuando el visitante pulsa «Enviar».

No hace falta prometer desde el principio una cifra de ventas ni convertir cada decisión en una métrica. Sí conviene acordar una señal observable: solicitudes recibidas, reservas completadas, consultas sobre una ficha o tiempo que deja de dedicarse a una tarea manual. Así, cuando la web esté funcionando, podrás preguntarte si resuelve el problema que motivó el proyecto y qué merece mejorar.

Identifica quién va a utilizarla

Cuando pensamos en una web, solemos imaginar a la persona que entra desde Google. Pero quizá alguien tenga que responder a su consulta, cambiar una fecha, aprobar un contenido o consultar una reserva. Si solo diseñamos para quien mira la pantalla pública, parte del trabajo real se queda fuera.

Haz una lista de personas, no de «usuarios» en abstracto. En una web de actividades puede haber quien descubre una visita, quien hace la reserva, quien atiende al grupo y quien organiza el calendario. No todas esas personas necesitan entrar en el mismo panel ni ver la misma información. Incluso puede que algunas no necesiten acceder a la web: bastaría con que recibieran un aviso claro en el momento adecuado.

Para cada persona, anota tres cosas: qué necesita saber, qué debe poder hacer y qué no debería poder cambiar. La última pregunta parece pequeña, pero evita errores muy concretos. Quien redacta una ficha quizá pueda guardarla sin publicarla; quien atiende reservas quizá deba consultar teléfonos, pero no modificar precios. Esos límites ayudan a definir permisos sin empezar por una lista técnica de roles.

Una misma acción también puede involucrar a varias personas. «El cliente reserva» puede significar que alguien comprueba la disponibilidad, otra persona prepara la actividad y una tercera consulta los datos el día de la visita. En el proyecto de Rancho Novo, por ejemplo, la gestión de reservas relaciona centros, contactos, fechas, participantes y talleres. Pensar en esas relaciones permite construir una herramienta de trabajo útil, no solo un formulario que recoge datos.

Hay una distinción que conviene hacer pronto: ¿las personas vendrán principalmente a leer y ponerse en contacto, o necesitarán entrar, consultar información propia y realizar tareas? Cuando la segunda parte domina el proyecto, puede que estemos hablando de una aplicación web a medida. Sigue usándose desde el navegador, pero su valor está en lo que permite hacer con personas, datos y procesos.

No necesitas diseñar ahora todas las pantallas ni inventar nombres para cada permiso. Basta con describir situaciones reales: «el cliente envía la solicitud», «alguien confirma la fecha», «el personal consulta los detalles antes de recibirlo». Si esas escenas están claras, será mucho más fácil decidir después qué parte debe ser pública, qué parte privada y qué información necesita cada cual.

Define las funcionalidades que realmente necesitas

«Quiero una web con buscador, área privada y automatizaciones» suena concreto, pero todavía deja lo esencial sin responder. ¿Qué se busca? ¿Quién entra en el área privada? ¿Qué tarea debería dejar de hacerse a mano? Una funcionalidad se entiende mejor cuando se describe como una acción dentro de una situación real.

En lugar de escribir nombres de herramientas, prueba con frases que empiecen así:

• «El visitante debe poder…» encontrar una actividad por fecha, comparar productos o calcular una opción antes de pedir presupuesto.
• «La persona que gestiona la web necesita…» revisar solicitudes, actualizar disponibilidad o corregir una ficha sin tocar otras partes del sistema.
• «Cuando ocurre esto, debería pasar aquello…» al confirmar una reserva, enviar los datos necesarios a quien prepara la actividad y dejar constancia de la confirmación.

Esas frases permiten distinguir funciones visibles, trabajo interno y tareas que pueden automatizarse. También muestran las excepciones. Si una reserva se cancela, ¿se libera la plaza? Si cambia un precio, ¿afecta a presupuestos ya enviados? La respuesta suele estar en cómo funciona tu negocio, no en el catálogo de un programa.

Un ejemplo de función muy específica es W2C: quien compra letras corpóreas puede componerlas visualmente y obtener un presupuesto según sus elecciones. Decir «necesito un configurador» habría sido demasiado vago. El problema real era conectar lo que la persona diseña con las reglas de cálculo del producto. Esa precisión ayuda a saber qué hay que construir y qué debe ocurrir cuando cambian las medidas, el material o el texto.

No todas las necesidades deben entrar en la primera versión. Para priorizarlas, pregunta cuáles son imprescindibles para completar el recorrido principal, cuáles eliminan un problema frecuente y cuáles pueden esperar sin impedir que la web cumpla su objetivo. Una función «por si acaso» puede añadir trabajo de contenido, soporte y mantenimiento durante años. Si aún no sabes cuánto se utilizará, quizá convenga preparar la web para incorporarla después y comprobar antes el uso real.

Hay además una frontera útil: si la mayor parte del encargo consiste en organizar personas, documentos, estados y tareas dentro de la empresa, ya no estamos definiendo solo funciones de una web comercial. En Proservi, por ejemplo, desarrollamos herramientas para gestionar personas, documentación y procesos de trabajo. Cuando esa operativa es el centro del proyecto, conviene pensarla como programación a medida para la empresa. Llamar correctamente al problema ayuda a plantear el alcance sin forzar todas las necesidades dentro de una única «web».

Piensa qué información tendrá que gestionar

Una web a medida no siempre se entiende contando sus páginas. Piensa en una tienda: «producto» parece una ficha, hasta que ese producto tiene tamaños, precios, existencias y pedidos. O en una reserva: parece un formulario, hasta que hay fechas, plazas, participantes, cambios y cancelaciones. Lo importante es saber qué información debe recordar la web y cómo se conecta.

No necesitas dibujar una base de datos. Empieza por los nombres que ya usáis al trabajar: clientes, actividades, reservas, productos, documentos, solicitudes. Después formula preguntas sencillas: ¿qué pertenece a qué?, ¿quién lo crea?, ¿quién lo modifica?, ¿cuándo deja de estar vigente? Una reserva pertenece a una actividad y a una fecha; una solicitud puede generar varias conversaciones; un pedido contiene varios artículos. Esas relaciones evitan que la información quede repartida en fichas que no se entienden entre sí.

Hay otra pregunta especialmente útil: ¿dónde está hoy el dato fiable? Si el precio se cambia en una hoja, el stock vive en la tienda y la información del cliente está en otra herramienta, copiarlo todo a una nueva web puede crear versiones contradictorias. Saber cuál es la fuente que manda permite decidir más adelante qué datos introducir, cuáles consultar y cuáles sincronizar. No hace falta elegir todavía el mecanismo técnico de esa conexión.

También conviene pensar en el recorrido de la información. Una solicitud puede pasar de recibida a revisada, presupuestada y cerrada. Si alguien corrige una dirección después de enviar un pedido, quizá deba conservarse la dirección original en ese pedido. No son detalles para diseñar a solas, pero un ejemplo real de cómo resolvéis esos cambios hoy ayuda a descubrirlos antes de que se conviertan en problemas.

En Renovatio, el trabajo alrededor de una reparación relaciona expedientes, asegurados, compañías, profesionales, documentación y movimientos económicos. Es un caso de software de gestión más amplio que una web comercial, pero muestra bien la idea: el valor no está en tener muchas pantallas, sino en que cada persona encuentre la información correcta dentro del proceso al que pertenece.

Para preparar tu proyecto, trae dos o tres ejemplos completos: un pedido normal, uno con cambios y uno que se haya complicado. Los casos excepcionales suelen enseñar más que una lista perfecta de campos. A partir de ellos podremos decidir qué información necesita realmente la web, qué debe conservar y qué puede seguir viviendo en otro sistema.

Decide qué contenido tendrá la web

Una ficha de producto puede estar muy bien diseñada y seguir sin ayudar a comprar si faltan las fotografías, las medidas o las condiciones de entrega. Con los servicios ocurre algo parecido: una página puede tener un formulario impecable y dejar al visitante sin entender qué se ofrece. Por eso el contenido no es lo que «se mete» al final en una web ya terminada; influye en cómo se organiza y se diseña desde el principio.

Haz un inventario sencillo de lo que ya existe: textos, fotografías, vídeos, fichas de productos o servicios, tarifas, documentos descargables, preguntas frecuentes y traducciones. No hace falta tenerlo todo terminado para comenzar, pero sí distinguir entre lo que está listo, lo que necesita revisión y lo que todavía hay que crear. Una carpeta de fotos antiguas no equivale necesariamente a tener las imágenes adecuadas para una tienda nueva.

Después asigna una persona responsable a cada tipo de material. ¿Quién sabe describir el servicio con precisión? ¿Quién puede confirmar precios y condiciones? ¿Quién tiene permiso para usar las fotografías? ¿Quién revisará una traducción antes de publicarla? «Ya lo prepararemos» suele ser una decisión sin dueño; si la producción del contenido forma parte del encargo, conviene decirlo y planificarla como cualquier otra parte del trabajo.

En Pequeños Detalles, por ejemplo, cada regalo puede cambiar según la ocasión, el texto, la imagen o la cantidad. La ficha necesita explicar esas opciones para que una persona pueda preparar su pedido. Aquí el contenido y la estructura de la ficha van juntos: no basta con disponer de una foto bonita ni con añadir campos de personalización sin explicarlos.

Hay otra distinción práctica: ¿qué información cambiará con frecuencia? Una presentación de la empresa quizá se revise de vez en cuando, mientras que actividades, artículos o disponibilidad pueden actualizarse cada semana. Saberlo ayuda a decidir qué debe poder editar vuestro equipo desde un panel y qué contenido necesita una estructura repetible. También permite preparar el trabajo diario después de publicar: quién dará de alta una nueva actividad, quién retirará una oferta caducada y qué ocurrirá cuando cambie una condición.

Si todavía falta mucho material, no hace falta detener la conversación. Trae una muestra real —una ficha completa, una propuesta comercial o las preguntas que más os hacen los clientes— y señala lo que falta. Diseñar alrededor de contenido representativo es mucho más útil que llenar pantallas con texto provisional y descubrir al final que la información verdadera no cabe.

Prepara tu identidad visual, si ya existe

Una web no empieza en una pantalla en blanco si tu empresa ya utiliza un logotipo, unos colores y una forma reconocible de comunicarse. Reúne lo que tengas: archivos del logo, fotografías propias, tipografías, piezas impresas, presentaciones, envases o incluso la web anterior. Todo eso ayuda a entender qué debe seguir siendo familiar para tus clientes.

Lo más útil no siempre es un manual de marca perfecto. A veces basta con poder decir: «Queremos conservar esta identidad, pero la web actual hace difícil encontrar nuestros servicios». Esa frase separa dos decisiones que suelen confundirse: cómo se reconoce la empresa y cómo encuentra una persona lo que necesita dentro de la web. La primera pertenece a la identidad visual; la segunda, al diseño de la interfaz. Pueden trabajarse juntas, pero resolver una no resuelve automáticamente la otra.

Si ya tienes materiales, intenta localizar los originales y no solo las copias que circulan por mensajería. Un logotipo pequeño y borroso puede servir para enseñar la idea, pero no para usarlo con calidad en todas las pantallas. Con las fotografías conviene aclarar cuáles representan de verdad tu actividad, cuáles están actualizadas y cuáles pueden publicarse. Si empleáis una tipografía de pago o imágenes de terceros, indica dónde se obtuvieron para revisar sus condiciones de uso antes de incorporarlas.

¿Y si todavía no tienes una identidad definida? No impide empezar a hablar del proyecto. Sí cambia su alcance: habrá que decidir si la marca se va a crear o ajustar antes de diseñar las pantallas, o si se puede avanzar en la estructura y coordinar ambas tareas. Lo importante es no tratar el color y el logo como un detalle que se añade al final, cuando la navegación y el contenido ya están cerrados.

Hay una prueba sencilla para orientar la conversación: muestra una página de tu negocio a alguien que no lo conozca. ¿Reconoce quién habla y qué ofrece? ¿Puede encontrar la siguiente acción sin que tengas que explicársela? Si falla lo primero, quizá haya que trabajar la identidad o el mensaje. Si falla lo segundo, la interfaz necesita atención. Si fallan ambos, conviene abordarlos de forma coordinada en lugar de pedir «una web más moderna» y esperar que esa frase lo resuelva todo.

Busca referencias de webs que te gusten

«Quiero una web como esta» es una buena forma de empezar una conversación y una mala forma de terminarla. La otra web quizá te atraiga por una fotografía, por lo fácil que resulta encontrar un producto o por un proceso de reserva que apenas exige esfuerzo. Son decisiones diferentes. Si señalas cuál de ellas te interesa, la referencia se vuelve útil.

Una manera sencilla de preparar referencias es guardar dos o tres enlaces y añadir una nota a cada uno:

• Referencia visual: «Me gusta la sensación de claridad de esta portada y cómo utiliza las fotografías». Hablas del aspecto, no necesariamente de la organización.
• Referencia de estructura: «Aquí encuentro los servicios por tipo de cliente y sé dónde ir después». Hablas del orden de la información y del recorrido.
• Referencia funcional: «Puedo elegir fecha, número de personas y terminar la reserva sin llamar». Hablas de una tarea que tu propia web quizá deba permitir.

Las tres referencias pueden venir de sitios distintos. De hecho, decir «me gusta el tono de A, encuentro fácilmente las respuestas en B y necesito un proceso de reserva parecido al de C» explica mucho más que pedir «una web moderna». Tampoco obliga a copiar ninguna: permite estudiar qué principio funciona y adaptarlo a tus clientes, tus contenidos y tu forma de trabajar.

Conviene mirar cada ejemplo también desde el móvil. Una página espectacular en un monitor puede esconder un menú incómodo, texto diminuto o un formulario interminable en el teléfono. Y, si algo no te gusta, anótalo: «en esta tienda no entiendo cuánto cuesta el envío hasta el final» es una referencia tan valiosa como una captura bonita. Ayuda a definir errores que quieres evitar.

No hace falta reunir veinte capturas ni justificar cada color. Para la primera conversación bastan unos pocos ejemplos acompañados de una frase sobre qué problema resuelven bien —o mal— para ti. Esa explicación es la materia prima; el diseño concreto de tu web vendrá después.

Define las integraciones con otros sistemas

Puede que tu futura web no trabaje sola. Una solicitud llega al programa donde seguís a los clientes; una venta debe reflejarse en la facturación; una reserva necesita aparecer en la agenda que ya utiliza el equipo. Si hoy alguien copia esos datos a mano de una pantalla a otra, ahí hay una conexión que conviene estudiar antes de diseñar el recorrido.

No hace falta llegar con una lista de «APIs» ni saber cómo se conectan dos programas. Empieza por nombrar las herramientas que ya usáis: gestión de clientes, facturación, reservas, correo comercial, pagos, documentos o incluso una hoja de cálculo. Para cada una, explica qué información entra, qué información sale y qué tarea hace hoy una persona entre medias. Esa última parte suele revelar el verdadero motivo de la integración.

Imagina que alguien reserva una visita en la web. La pregunta no es solo «¿se conecta con el calendario?», sino: ¿la web consulta las plazas disponibles o el calendario recibe la reserva después? ¿Cuándo se confirma? ¿Qué ocurre si la conexión falla? ¿Quién corrige una reserva duplicada? Responder a esto permite decidir qué sistema tiene el dato fiable y evita que dos herramientas muestren disponibilidades distintas.

En Cadizfornia Tours, el recorrido de las experiencias y las reservas ha evolucionado: partió de una central propia y después incorporó FareHarbor. Es un buen ejemplo de por qué importa conocer el proceso de negocio antes de elegir una conexión concreta. La herramienta puede cambiar; la necesidad de presentar una experiencia y conducir a su reserva permanece.

Para preparar el encargo, basta con un pequeño mapa de trabajo: «El cliente rellena esto → nuestro equipo lo recibe aquí → copiamos estos datos a este programa → confirmamos por este canal». Si conoces quién administra cada herramienta y si existe documentación o un entorno de pruebas, anótalo. No compartas contraseñas en ese documento inicial; los accesos se pueden organizar de forma segura cuando se concrete el trabajo.

Algunas conexiones son sencillas y otras dependen de las posibilidades reales del servicio externo. Por eso conviene comprobarlas antes de prometer que todo será automático. Las integraciones y funciones específicas de una web se definen a partir de ese intercambio de información, no de una lista de logotipos de herramientas que «deberían conectarse».

Dominio, alojamiento y correo electrónico

«Antes de llamar, ¿tengo que comprar un dominio y contratar un servidor?». No necesariamente. Si tu empresa ya tiene una web, seguramente parte de eso existe. Si empieza de cero, conviene elegirlo sabiendo qué vamos a construir, no comprando el primer plan que aparece en una comparativa.

El dominio es la dirección que las personas escriben para llegar a tu web. El alojamiento es donde funciona la web. Y el correo corporativo puede depender de otros servicios aunque utilice ese mismo dominio. Entender esta separación evita un error frecuente: pensar que cambiar de web obliga a cambiar también las cuentas de correo, o modificar la configuración del dominio sin saber a qué más afecta.

Si ya utilizas un dominio, intenta averiguar quién lo registró, quién puede renovarlo y quién administra su configuración. Si hay web y correo en funcionamiento, anota dónde están alojados y quién tiene acceso administrativo. No necesitas enviar contraseñas con el primer mensaje; basta con saber qué cuentas existen y quién puede facilitar el acceso de forma segura cuando haga falta. Lo importante es que estos activos estén bajo control de tu empresa o puedan transferirse con claridad.

Si aún no hay alojamiento, deja esa elección para cuando conozcamos el proyecto. Una web que presenta servicios y recibe consultas no tiene las mismas necesidades que una aplicación con usuarios, archivos, procesos programados o picos de reservas. También habrá que considerar copias de seguridad, mantenimiento, disponibilidad y capacidad de crecimiento. Elegir un servidor demasiado pronto puede obligar a adaptarse a sus límites; elegirlo después permite ajustarlo al trabajo real.

Cuando se sustituye una web existente, la publicación merece una pequeña lista de comprobación: que la dirección siga llevando a la web, que el correo continúe llegando, que las páginas importantes tengan su destino correcto y que exista una copia recuperable de lo anterior. Es una transición que se planifica, no un botón que se pulsa a ciegas. Si la infraestructura requiere una intervención específica, la administración de sistemas y servidores se ocupa de esa parte sin convertirla en una decisión que tengas que resolver tú antes de explicar tu necesidad.

Si ya tienes una web, determina qué debe conservarse

«Queremos una web nueva» no significa necesariamente «queremos borrar la anterior». Esa web puede contener años de fotografías, páginas que reciben visitas, clientes registrados, productos, pedidos o documentos que el equipo consulta a diario. También puede haber pequeñas funciones que nadie recordó mencionar porque llevan tanto tiempo funcionando que parecen invisibles.

Antes de decidir si conviene renovar, reconstruir o ampliar, haz un inventario de lo que la web actual hace de verdad. No mires solo la portada. Recorre una solicitud completa, un pedido con incidencia, la edición de un producto y las tareas del panel de administración. Pregunta a las personas que lo usan qué les ayuda y qué les obliga a buscar soluciones fuera de la web. A veces el problema está en un paso concreto y no en toda la plataforma.

En ese inventario separa tres grupos:

• Lo que el público ya encuentra: páginas, direcciones web, textos, imágenes y contenido que recibe visitas o consultas. Cambiarlo sin plan puede hacer que una persona —o un buscador— deje de llegar a la respuesta que conocía.
• Lo que el negocio necesita conservar: clientes, pedidos, reservas, documentos, productos, permisos e historial. No todo se puede trasladar de la misma forma; conviene decidir qué debe seguir siendo consultable y qué puede archivarse.
• Lo que mantiene la actividad en marcha: correo, formularios, pagos, herramientas conectadas, analítica, dominio y tareas que ocurren automáticamente. Muchas de estas dependencias no se ven desde la página pública.

Después se puede marcar cada elemento como conservar, mejorar, sustituir o retirar. No es un ejercicio burocrático. Sirve para evitar dos errores opuestos: rehacer algo que ya resolvía bien una necesidad y arrastrar a la nueva web una complicación que nadie quiere mantener.

En Pequeños Detalles trabajamos sobre una tienda en funcionamiento, adaptando fichas, reglas comerciales, módulos e integraciones. Ese caso muestra que evolucionar una plataforma útil puede tener más sentido que sustituirla cada vez que aparece una necesidad nueva. La decisión depende de lo que la base actual permite hacer y del coste real de conservarla.

Si finalmente hay que cambiar de plataforma, la publicación no termina al copiar el contenido. Habrá que preparar una copia recuperable, comprobar los datos trasladados, probar las tareas importantes y decidir a dónde llevará cada dirección antigua. Ese trabajo se define antes del cambio, cuando todavía se puede comparar la web nueva con la anterior y detectar lo que falta.

Piensa en el SEO antes de desarrollar la web

El posicionamiento en buscadores no empieza cuando la web ya está publicada y alguien pregunta dónde colocar las palabras clave. Empieza antes, al decidir qué necesita encontrar cada persona y qué página va a responderle. Esa decisión afecta al contenido, a la navegación y, si ya existe una web, a lo que conviene conservar.

Imagina una empresa que ofrece mantenimiento, instalación y reparación, pero explica los tres servicios en un único párrafo de la portada. Una persona que busca una reparación urgente necesita saber si atendéis ese problema, dónde trabajáis y cómo contactar. Quien estudia una instalación nueva necesita otra información. Si ambas necesidades se mezclan, la web puede quedar clara para quien ya conoce la empresa y confusa para quien acaba de descubrirla.

Preparar el SEO en esta fase no significa inventar una página para cada variante de una frase. Significa identificar las preguntas y decisiones distintas que tienen tus clientes, agrupar las que pueden resolverse juntas y dar una respuesta propia a las que necesitan profundidad. Después se puede decidir qué páginas tendrá la web, cómo se relacionarán y qué términos utilizará la gente para encontrarlas. La arquitectura nace de la intención, no de repetir una palabra en todos los títulos.

Si ya tienes páginas que reciben visitas, anota cuáles son y qué necesidad cubren. Una reconstrucción puede cambiar el aspecto de la web sin cambiar sus direcciones; si alguna dirección debe cambiar, hay que decidir cuál será su destino equivalente. La guía de Google para cambios de URL recomienda preparar esa correspondencia y las redirecciones antes de la migración. En términos sencillos: quien guardó un enlace antiguo debería seguir llegando a la información que buscaba, no aterrizar sin explicación en la portada.

No tienes que llegar con una investigación completa de búsquedas. Basta con traer las preguntas que te hacen tus clientes, los servicios que realmente quieres explicar y, si existe, acceso a los datos de búsqueda de la web anterior. Si captar visitas orgánicas es una parte importante del proyecto, la arquitectura de posicionamiento SEO debe definirse antes de publicar, para que cada página tenga una función clara y la nueva web no pierda respuestas valiosas por el camino.

Decide qué quieres medir

Un panel lleno de gráficos puede dar sensación de control y, aun así, no ayudar a tomar una sola decisión. Antes de pedir «poner Analytics», pregúntate qué querrás saber cuando la web lleve un tiempo funcionando. La herramienta se elige después; primero va la pregunta.

Si el objetivo es recibir solicitudes, quizá quieras saber cuántas llegan, desde qué páginas y cuántas contienen la información necesaria para responder. Si permites reservar, puede interesarte distinguir a quienes consultan una fecha, empiezan el proceso y lo completan. En una tienda, además de saber qué productos se miran, necesitas conocer cuáles acaban en pedidos. Cada pregunta pide señales distintas.

Una forma práctica de preparar la medición es escribir una frase con tres partes: «Quiero saber [qué ocurre] para decidir [qué haré si cambia]». Por ejemplo: «Quiero saber si las personas encuentran las condiciones de la actividad antes de reservar, para mejorar la ficha si abandonan al llegar al pago». Eso permite diseñar qué observar sin registrar cada clic por inercia.

También importa distinguir un dato registrado de un resultado real del negocio. Una plataforma publicitaria puede atribuirse una conversión; la herramienta de analítica puede contar una visita; el sistema de pedidos confirma si hubo una compra. Son piezas de una misma historia, no cifras intercambiables. En Pequeños Detalles contrastamos visitas y conversiones atribuidas con los pedidos efectivos de la tienda antes de sacar conclusiones sobre la captación.

No todo se conoce desde el navegador. Una solicitud puede convertirse en cliente días después por teléfono, y una reserva puede cancelarse. Si esas decisiones importan, habrá que plantear cómo unir la información de la web con el seguimiento comercial o con el sistema que gestiona la actividad. En cambio, si nadie va a utilizar un dato para decidir nada, quizá no merezca la complejidad de recogerlo.

Para empezar bastan tres o cuatro preguntas ligadas al objetivo principal que definiste al principio del proyecto. Con ellas se puede decidir qué medir desde la primera versión, cómo interpretar los resultados y qué revisiones harán falta más adelante. La medición debe ayudarte a mejorar la web, no convertirla en un escaparate de números.

Aspectos legales que puede necesitar la web

Hay decisiones legales que cambian cómo debe funcionar una web. No se resuelven pegando al final una política de privacidad genérica. Si recoges datos en un formulario, vendes online, instalas herramientas de medición o permites crear una cuenta, conviene identificarlo antes de diseñar esas funciones.

Por ejemplo, un formulario necesita explicar para qué se usarán los datos y permitir gestionar las solicitudes de las personas. Una tienda debe mostrar con claridad las condiciones aplicables a la compra. Si se utilizan cookies no necesarias para el servicio, su configuración afecta a cuándo se cargan ciertas herramientas y a cómo se recoge la elección del visitante; la guía de cookies de la AEPD describe las opciones de aceptación, rechazo y configuración. No es solo un texto que se coloca en el pie de página.

También hay que pensar en la accesibilidad: que se pueda leer, navegar y completar las tareas importantes con distintas capacidades y dispositivos. Según la actividad y quién ofrece el servicio, pueden existir obligaciones específicas adicionales. Una web de reservas, una tienda y una herramienta que gestiona información sensible no tienen por qué necesitar exactamente las mismas condiciones.

Para preparar el proyecto, anota qué datos personales se van a recoger, qué operaciones hará la web y si intervienen proveedores externos. Con esa información se pueden traducir las obligaciones aplicables en requisitos de diseño y funcionamiento, y pedir la revisión jurídica que corresponda. La decisión legal debe tomarla quien asesora a tu empresa en esa materia; el desarrollo debe poder implementarla correctamente.

Decide quién mantendrá la web después de publicarla

Publicar la web es el comienzo de su uso real, no el momento en que deja de necesitar atención. Aparecerán contenidos nuevos, preguntas de los clientes, cambios en los servicios y, tarde o temprano, algo que habrá que corregir. Si nadie sabe quién se ocupa de cada cosa, una mejora pequeña puede quedarse esperando semanas o una incidencia puede descubrirse cuando ya afecta a los usuarios.

Conviene separar tres trabajos que suelen llamarse simplemente «mantenimiento». Mantener es conservar el funcionamiento: revisar actualizaciones, copias, infraestructura y servicios conectados. Dar soporte es atender dudas e incidencias: investigar por qué no llega un formulario o ayudar a alguien a usar el panel. Desarrollar es incorporar una capacidad nueva: otro tipo de reserva, una integración o un cambio importante en el proceso. Pueden hacerlos las mismas personas, pero no son la misma tarea ni tienen el mismo alcance.

Antes de contratar, pregunta quién administrará el dominio, el alojamiento y las copias; quién podrá restaurar la web si algo falla; quién actualizará textos y fichas; y cómo se avisará de una incidencia. Si la web depende de una pasarela de pago, un sistema de reservas o un proveedor de correo, también interesa saber quién comprobará que esas conexiones siguen funcionando cuando alguno cambie.

Esto no significa que debas contratar desde el primer día un paquete cerrado para todo. Puede que tu equipo gestione los contenidos y encargue la parte técnica fuera. O que al principio necesites acompañamiento para aprender a usar la herramienta y, después, solo intervenciones puntuales. Lo importante es acordar responsabilidades, forma de contacto y criterios de prioridad antes de que aparezca un problema urgente.

Una web hecha a medida debe poder evolucionar. Si hoy solo recibe solicitudes y mañana también permite reservar, conviene que el proyecto pueda incorporar esa función sin reconstruir todo lo que ya sirve. Mantener lo que funciona y desarrollar lo nuevo serán decisiones distintas. Si necesitas un responsable para la continuidad técnica, el mantenimiento web es una parte diferenciada del desarrollo inicial.

Qué información permite calcular el presupuesto

Para presupuestar una web a medida no basta con decir «necesito algo parecido a esta página». El precio depende del trabajo que habrá que definir, diseñar, construir y comprobar. Dos webs que parecen igual de sencillas desde fuera pueden esconder cantidades de trabajo muy distintas.

Por qué contar páginas no basta para presupuestar una web a medida

Imagina una web con treinta páginas informativas que comparten la misma estructura. Una vez diseñado el modelo, buena parte del trabajo consiste en preparar y cargar contenido. Ahora imagina una sola pantalla donde una persona configura un producto, ve cómo cambia, recibe un precio calculado según varias condiciones y puede terminar un pedido. Hay menos «páginas», pero muchas más decisiones, reglas y pruebas.

El proyecto W2C ilustra bien esa diferencia. Quien compra puede componer visualmente unas letras corpóreas; detrás, un sistema interpreta medidas, materiales y otras elecciones para calcular el presupuesto. Lo que se ve como un editor en una pantalla reúne una interfaz, reglas de negocio y un recorrido de compra. Contar esa pantalla como «una página» ocultaría casi todo el trabajo.

Por eso ayudan más los recorridos que un número de apartados: «el cliente selecciona», «el sistema comprueba», «el equipo revisa» y «se confirma el pedido». Cada paso puede tener estados, permisos y casos excepcionales. A eso se suman el contenido que hay que producir, las herramientas que deben conectarse, los datos que hay que trasladar desde una web anterior y las pruebas necesarias para publicar con seguridad.

Para pedir una estimación útil, intenta separar lo imprescindible para la primera versión de lo que podría venir después. Indica si ya existen textos, fotografías, marca, dominio y datos que deban migrarse. Muestra un ejemplo real del proceso más importante y señala las dudas que todavía tenéis. No hace falta ocultarlas para que el proyecto parezca más definido: conocer la incertidumbre permite decidir qué hay que investigar antes de fijar un alcance.

Un presupuesto serio debería dejar claro qué resultado se va a entregar, qué supuestos se han utilizado y qué partes requieren definición adicional. Si el comportamiento de una función aún es desconocido, puede tener sentido trabajar primero su análisis o dividir el proyecto en fases. Eso permite comparar propuestas por lo que resuelven, no solo por una cifra final que quizá esté calculada sobre ideas distintas. Si quieres iniciar esa conversación con lo que ya sabes, puedes contarnos el proyecto para preparar un presupuesto.

Qué determina cuánto tarda un desarrollo web

La pregunta «¿cuánto tardará?» merece una respuesta útil, no una cifra repetida para cualquier proyecto. El plazo depende del trabajo que hay que hacer y también del orden en que pueden tomarse las decisiones. Diseñar una pantalla es difícil si aún no se sabe qué información mostrará; probar una reserva completa exige que el sistema con el que se conecta esté disponible.

Hay tareas que pueden avanzar a la vez, como preparar fotografías mientras se define la estructura. Otras dependen de una anterior: no se puede validar el recorrido de compra sin conocer las condiciones del producto, ni migrar datos que todavía no se han localizado. Por eso el calendario debe reflejar entregas, revisiones y dependencias, además de horas de diseño y desarrollo.

La incertidumbre también cuenta. «El cliente elige una fecha disponible y recibe confirmación» permite estimar mejor que «queremos un sistema de reservas parecido al de nuestra competencia». La segunda idea necesita descubrir reglas: plazas, cancelaciones, pagos, cambios de fecha y quién decide en cada caso. Ese análisis forma parte del proyecto; esconderlo detrás de una fecha cerrada no lo hace desaparecer.

Las respuestas de terceros pueden marcar el ritmo. Quizá haya que esperar la documentación de un proveedor, acceso a un sistema anterior o la aprobación de unos textos. También interviene la disponibilidad de quien revisa por parte del cliente. Si una decisión se queda sin responsable, una semana sin respuesta puede afectar más al calendario que una pantalla compleja.

¿Hay una fecha que no puede moverse, como una feria o el inicio de una campaña? Dilo desde el principio. Puede ser razonable publicar primero el recorrido imprescindible y dejar otras funciones para una fase posterior, siempre que esa primera versión sirva realmente a sus usuarios. Lo que no conviene es llamar «versión inicial» a una web que todavía no permite completar la tarea para la que se encargó.

Para conversar sobre el plazo, trae tres datos: qué debe estar operativo en la fecha deseada, qué materiales y accesos están disponibles y quién podrá revisar las decisiones. Con eso se puede proponer un calendario que incluya tiempo para probar, corregir y publicar; no solo una fecha de entrega dibujada al final de una propuesta.

Qué documentación deberías entregar al desarrollador

La palabra «documentación» puede hacer pensar en un informe largo y formal. Para empezar no hace falta. Una página escrita con tus palabras y dos o tres ejemplos del trabajo diario suelen enseñar más que un documento lleno de términos técnicos copiados de otra propuesta.

Ese resumen puede responder a tres preguntas. ¿Qué hace la empresa y qué problema quiere resolver? ¿Quién utilizará la web y qué debería poder hacer? ¿Cómo se hace hoy ese trabajo? Después añade lo que ya sabes: funciones imprescindibles, contenido disponible, sistemas con los que habrá que conectar, web anterior si existe y una fecha importante si la hay. Señala también quién podrá tomar decisiones y revisar el resultado por parte de tu empresa.

Lo más revelador suele estar en los ejemplos concretos. Si hoy recibís reservas por correo, un mensaje real sin datos personales puede mostrar qué pregunta el cliente, qué respuesta enviáis y dónde anotáis la fecha. Si calculáis precios en una hoja, una copia con datos de prueba puede revelar reglas que no aparecen en la frase «necesitamos presupuestos automáticos». Si después generáis un documento, enseña cómo es y quién lo necesita.

No tienes que convertir esos materiales en un esquema de pantallas ni decidir qué programa se utilizará. El trabajo de análisis consiste precisamente en pasar de escenas como «recibimos este correo, comprobamos esta hoja y respondemos así» a requisitos que se puedan diseñar y probar. También aparecerán preguntas nuevas; eso indica que el ejemplo está ayudando a descubrir el proyecto.

Procura distinguir lo confirmado de lo que todavía es una idea. «Siempre pedimos el teléfono antes de reservar» describe una regla actual; «quizá nos gustaría ofrecer pagos online» abre una posibilidad que habrá que valorar. Ambas cosas importan, pero no deberían entrar en el presupuesto con el mismo grado de certeza.

Si solo puedes preparar una cosa antes de hablar, prepara un recorrido completo: qué lo inicia, qué hace cada persona, qué información se usa y cómo sabes que ha terminado bien. Ese recorrido será una base mucho más sólida para la conversación que una lista de funciones deseadas sin contexto.

Qué no necesitas preparar antes de pedir una web a medida

Después de leer todo esto podrías pensar que necesitas llegar a la primera reunión con el proyecto completamente resuelto. Sería justo lo contrario de la idea de esta guía. Tu trabajo es explicar tu negocio y la necesidad que quieres cubrir; convertirla en una solución comprobable forma parte del encargo profesional.

No tienes que escoger un lenguaje de programación, una base de datos, un proveedor de servidores o la estructura interna del sistema. Esas decisiones dependen de las funciones, los datos, las herramientas con las que habrá que conectar y quién mantendrá la web. Elegirlas antes de entender el problema puede cerrar opciones útiles sin aportar ninguna ventaja.

Tampoco hace falta presentar pantallas diseñadas al detalle. Un boceto hecho a mano puede ayudar a explicar una idea, pero no es un requisito para pedir una web. Si dibujas un botón que dice «Reservar», lo valioso no es su forma ni su posición exacta: es la pregunta que abre. ¿Qué información necesita la persona para reservar y qué ocurre después de pulsarlo?

Una especificación de veinte páginas tampoco convierte automáticamente una idea en un proyecto claro. A veces describe con precisión decisiones que todavía no se han contrastado con quienes usarán la web. Es más útil señalar «esto lo hacemos siempre», «esto ocurre solo en algunos casos» y «esto aún no sabemos si lo necesitamos». Así se puede investigar lo incierto sin tratarlo como una promesa cerrada.

No esperes a tener todos los textos, todas las fotos y una respuesta para cada excepción si eso te impide empezar. Indica qué material existe, quién puede prepararlo y qué falta decidir. Con un problema bien contado, un objetivo principal y un ejemplo real del proceso actual ya se puede mantener una conversación productiva. Lo demás se irá definiendo con el alcance y las prioridades a la vista.

De la idea a los requisitos: cómo debería empezar un proyecto web a medida

Una idea suele llegar en forma de deseo: «queremos organizar mejor las reservas» o «necesitamos que el cliente pueda configurar su pedido». Para construir algo útil hay que convertir ese deseo en situaciones que se puedan diseñar, poner a prueba y reconocer cuando estén resueltas. Eso es definir requisitos; no es traducir la idea a una lista de tecnologías.

El recorrido empieza por observar el trabajo actual. ¿Qué lo inicia? ¿Quién interviene? ¿Qué información necesita? ¿Qué decisiones toma? ¿Qué pasa cuando algo se sale de lo normal? A partir de esas respuestas se puede acordar el objetivo, distinguir lo imprescindible de lo deseable y describir el comportamiento esperado. Solo entonces tiene sentido decidir las pantallas, los sistemas que se conectarán y la solución técnica.

Por ejemplo, Eleka necesitaba coordinar eventos audiovisuales con equipos, vehículos y personal. «Un calendario de eventos» habría descrito solo una parte visible. El trabajo real exigía relacionar cada evento con los recursos que necesita y con las personas que participan. De esa comprensión salió una aplicación interna de gestión, distinta de una simple web de presentación.

Un requisito útil se puede contar como una escena: «Cuando se prepara un evento, la persona responsable debe poder consultar sus fechas y los recursos asignados para organizar el trabajo». Esa frase todavía puede abrir preguntas —qué recursos, quién puede cambiarlos, qué ocurre ante un cambio de fecha—, pero ya señala algo que se podrá comprobar. «Hacer un panel moderno» no permite saber si la necesidad se resolvió.

El resultado de esta fase no tiene que ser un documento enorme. Puede ser un conjunto acordado de recorridos, reglas conocidas, dudas pendientes y prioridades. Sirve para diseñar con propósito, presupuestar un alcance comparable y probar después la web con casos parecidos a los que ocurren en la empresa. Si alguna regla sigue siendo incierta, se investiga antes de tratarla como si estuviera decidida.

Lista de comprobación: qué necesitas para empezar tu web a medida

Si vas a pedir una primera conversación, no necesitas llevar todas las respuestas cerradas. Usa esta lista para reunir lo que ya sabes y marcar lo que habrá que descubrir juntos. Una respuesta aproximada y un ejemplo real valen más que una casilla rellenada por compromiso.

¿Te faltan varias respuestas? No pasa nada. La lista sirve para señalar qué hay que averiguar, no para examinarte antes de poder pedir ayuda. Si solo puedes traer el problema, una persona a la que afecta y un ejemplo de cómo lo resolvéis hoy, ya hay materia para empezar.

¿Y si solo tienes una idea y todavía no sabes definir todo esto?

Puedes llegar con un documento completo, una web que ya funciona a medias o una frase tan sencilla como «perdemos tiempo pasando reservas de un sitio a otro». Las tres son formas válidas de empezar. La primera tarea no es elegir una herramienta: es entender qué ocurre, a quién afecta y qué cambio merecería la pena construir.

Si la necesidad está dentro de tu web —una función, un configurador, un módulo o una conexión con otro servicio—, el siguiente paso encaja en el desarrollo específico para tu web. Si lo que quieres ordenar es una parte más amplia del trabajo de la empresa, con personas, datos, tareas y decisiones propias, conviene estudiarlo como software y programación a medida. No tienes que saber por adelantado en cuál de los dos casos estás; esa frontera se aclara al revisar la necesidad.

Si te ayuda ver cómo han terminado otras ideas, consulta los proyectos de programación a medida: hay encargos muy diferentes que empezaron por comprender un problema concreto antes de convertirse en una herramienta. Y si prefieres hablar de tu caso, cuéntanos qué necesitas, aunque todavía no tengas todas las respuestas de la lista. Un ejemplo de lo que pasa hoy es suficiente para comenzar.