18 de agosto de 2026

Visión general

EVH Renovatie instala ventanas, puertas y carpintería exterior en Putte, Bélgica. Sus clientes son propietarios de vivienda en un radio de unos treinta kilómetros que están eligiendo entre tres instaladores locales, y que tomarán esa decisión desde el teléfono, por la noche, en neerlandés. El sitio tiene un solo trabajo: convertir esa búsqueda en una solicitud de presupuesto. Lo diseñé y construí de punta a punta.

Investigación UX

La investigación aquí no es un ejercicio de entrevistas con stakeholders, es entender una decisión de compra concreta.

• La búsqueda es local y específica. Nadie busca «renovación». Buscan un producto y un lugar: screens, rolluiken, una veranda, mosquiteras. Eso significa que una página por servicio, capaz de posicionar por sí sola, gana a una sola página de servicios con anclas.
• La confianza es visual e inmediata. Un propietario que compara instaladores busca evidencia de calidad de acabado. Las fotografías de trabajos terminados hacen más que cualquier cantidad de texto, así que el portafolio es una página principal y no una nota al pie.
• El teléfono es la conversión. Muchos clientes no llenarán ningún formulario; van a llamar. Por eso el número está en el encabezado de todas las páginas, permanente y pulsable.
• Las dos solicitudes son distintas. «Tengo una pregunta» y «quiero un precio para este trabajo» necesitan campos distintos. Forzar ambas por un solo formulario pierde la segunda, que es la valiosa.

Dirección de UI

• La fotografía sostiene la página. Un hero a sangre completa con trabajo real instalado, fotografiado en obra, con el texto encima. El producto es el oficio, así que la imagen es el argumento.
• Una paleta cálida e industrial: carbón y un solo naranja de construcción para la acción. Suficientemente sobria para leerse profesional, suficientemente cálida para no sentirse corporativa.
• Neerlandés llano y seguro. Ramen & deuren op maat. Sin eslóganes ni relleno. Un cliente de oficio quiere saber qué haces y dónde lo haces, en la primera frase.
• Primero móvil, porque el tráfico lo es. Áreas de toque grandes, un encabezado que mantiene el teléfono al alcance y formularios cortos para terminarlos de pie.

Características clave

• Nueve páginas de servicio —ventanas, puertas, muros cortina, verandas, screens, rolluiken, trabajos de sellado y mosquiteras— cada una una página real con sus propios metadatos y datos estructurados, no una pestaña.
• Portafolio filtrable: proyectos terminados filtrados por categoría, cada uno con una fotografía y una descripción breve del trabajo.
• Una página de contacto de dos modos: una pestaña de consulta general y otra de solicitud de presupuesto que captura el servicio, la localidad y los detalles que un instalador necesita para cotizar sin una segunda llamada.
• Datos de contacto como contenido: dirección, teléfono, correo y horarios expuestos donde el cliente los busca, no escondidos detrás de un formulario.
• Un backend autogestionable: los envíos llegan a una base que el cliente puede leer, junto a los proyectos del portafolio y los testimonios, para que el contenido del sitio sea suyo.

Arquitectura

Un sitio en React que se publica como HTML estático. El sitio está construido con Vite y React, pero no se publica como una aplicación de una sola página renderizada en el cliente. Un paso posterior al build renderiza en servidor cada una de las doce rutas y escribe un archivo HTML estático por ruta, con el head completo —título, meta, canónica, Open Graph y todos los datos estructurados— y el cuerpo ya renderizado. El cliente luego hidrata ese mismo marcado. Esto importa exactamente por la razón por la que el sitio existe. Un crawler o un scraper social sin JavaScript sigue viendo metadatos correctos y contenido real, y un propietario con datos móviles ve la página de inmediato en vez de un spinner. Para un negocio cuyo canal de captación completo es la búsqueda local, entregar una cáscara vacía a un crawler habría sido la decisión más cara disponible. Un backend que el cliente puede poseer. El contenido y los envíos de formularios corren sobre PocketBase, un backend autoalojado que se distribuye como un único binario con su propio panel de administración. Las colecciones de contactos, solicitudes de servicio, proyectos y testimonios están versionadas como migraciones. Para un negocio pequeño encaja mejor que una plataforma de contenidos alojada: sin costo por usuario, sin una cuenta de proveedor que gestionar, y todo es un archivo que le pertenece. Alojamiento. El build estático se despliega en Netlify. Los recursos con hash reciben caché inmutable de un año, las rutas válidas sirven su propio archivo pre-renderizado, y las URL desconocidas caen a la cáscara de la app. Una página retirada redirige de forma permanente en vez de dar 404, porque un enlace muerto que antes posicionaba es un activo desperdiciado.

Tecnologías utilizadas

• Frontend: React con Vite, React Router, Tailwind CSS, primitivas de Radix UI con class-variance-authority, Framer Motion para transiciones sobrias, íconos de Lucide.
• SEO: react-helmet para metadatos por ruta, una pipeline propia de renderizado en servidor y pre-render, datos estructurados JSON-LD y un resumen del sitio legible por máquinas.
• Backend: PocketBase, autoalojado, con migraciones versionadas de colecciones y límites de tasa configurados.
• Imágenes: Sharp para el procesamiento de imagen en tiempo de build.
• Alojamiento: Netlify, con cabeceras de caché y reglas de redirección explícitas.

Retos y aprendizajes

Una app de una sola página es el valor por defecto equivocado para un negocio local. El reflejo moderno es publicar una app renderizada en cliente y añadir una librería de metaetiquetas. Para un sitio cuyos clientes llegan desde una búsqueda de Google en el teléfono, eso sacrifica las dos cosas que más importan: lo que ve el crawler y cuán rápido pinta la primera vista. Construir el paso de pre-render fue el trabajo de mayor apalancamiento del proyecto y nada de él se ve. Nueve páginas casi idénticas necesitan un modelo de contenido, no nueve archivos. Los servicios comparten estructura y difieren en contenido. Manejarlos desde un solo módulo de datos los mantiene consistentes y convierte añadir el décimo servicio en un cambio de datos y no en otra página que mantener. Elige el backend con el que el cliente pueda vivir. PocketBase no es la opción más potente disponible. Es un binario, con un panel que un contratista puede usar de verdad, y sin una factura mensual que dentro de un año se vuelva una conversación incómoda. Ajustar la herramienta a quien la mantiene después es parte del diseño.

Resultado

Un sitio rápido, totalmente estático y en neerlandés donde cada servicio tiene su propia página posicionable, el trabajo terminado está al frente, el teléfono está siempre a un toque, y una solicitud de presupuesto llega con detalle suficiente para cotizar el trabajo. El cliente es dueño de su contenido y de su bandeja de entrada, y el sitio carga antes de que un propietario con datos móviles pierda la paciencia.