Alex HerreraDesarrollador de Software · Enfoque en Ciberseguridad
EN
← Volver a proyectos

Profesional

Kaizen Apps | Sitio corporativo

Sitio bilingüe de la empresa, con las demostraciones de producto bajo el mismo dominio y un formulario de reserva que llega a una persona.

  • Full Stack
  • Seguridad

1 / 9

Portada de kaizenapps.net en español, con el conmutador de idioma y de tema en la cabecera

Portada en español, con el conmutador de idioma y de tema en la cabecera.

Rol
Desarrollo
Periodo
2026-01 — Actualidad

Stack

  • Astro
  • TypeScript
  • React
  • Tailwind CSS
  • Cloudflare Turnstile
  • Resend
  • Render

Contexto

Kaizen Apps vende software a medida, así que su sitio es el primer contacto comercial y el lugar donde un prospecto ve el producto funcionando antes de hablar con nadie.

El encargo fue rehacerlo entero: las páginas de marketing en español e inglés, las demostraciones de las aplicaciones bajo el mismo dominio y un canal de reserva que no dependa de que alguien revise un buzón compartido.

Problema

El sitio anterior no traía metadatos de posicionamiento. No había títulos ni descripciones por página, ni relación declarada entre la versión en español y la inglesa, de modo que un buscador no tenía forma de saber que eran la misma página en dos idiomas.

Las aplicaciones que la empresa vende viven cada una en su propia dirección, fuera del sitio. Un prospecto que quería verlas funcionando salía del sitio comercial y, una vez fuera, no tenía manera de volver ni de pasar a la siguiente.

Decisiones técnicas

Las rutas se declaran en un solo archivo. Cada página lleva ahí su identificador, sus dos rutas y sus metadatos, y de esa misma tabla salen el menú y el mapa de equivalencias entre idiomas que alimenta el cambio de idioma. Añadir una página es añadir una entrada, no recorrer seis archivos.

El sitio es estático salvo donde no puede serlo. Solo la reserva necesita servidor, así que solo ella se sirve como ruta de servidor; el resto se genera en el build. Eso permitió llevarlo de un alojamiento a otro cambiando el adaptador, sin tocar las páginas.

Las ocho páginas que envuelven una demostración eran ocho copias del mismo HTML. Se redujeron a una función compartida a la que cada ruta delega: el menú flotante y la política del marco se editan en un archivo, no en ocho.

El reto anti-robot se valida contra Cloudflare desde el servidor, no en el navegador, y la respuesta pública no distingue entre un token inválido, un campo mal formado y un fallo del servicio de correo. El código real se registra del lado servidor.

Arquitectura

El sitio tiene tres clases de página. Las de marketing son estáticas y bilingües, generadas desde la tabla de rutas. Las envolturas de demostración son respuestas HTML que montan la aplicación correspondiente dentro del sitio. Y hay un único endpoint de servidor, el de la reserva.

FormularioVerificaciónAPICorreo

El formulario obtiene un token de Cloudflare Turnstile y el servidor lo valida contra Cloudflare antes de mirar el resto del envío. El navegador no decide si el reto se superó.

Tipo, presencia y longitud de cada campo se verifican en el servidor. Un envío que no cumple no llega ni a la verificación del reto ni al correo.

La respuesta pública dice que el envío falló y nada más. El código de error real queda en el registro del servidor, donde no orienta a quien prueba el formulario a ciegas.

En el HTML viaja únicamente la clave pública del reto. La clave secreta y la del servicio de correo existen solo en el entorno del servidor.

El único endpoint público del sitio, con cuatro reglas antes de que un envío se convierta en correo.

Resultado

El sitio se publica en español e inglés desde una sola definición de rutas, con los metadatos de cada página y la correspondencia entre idiomas declaradas donde se declara la página.

Las demostraciones quedaron bajo el mismo dominio y comparten navegación, de modo que un prospecto puede recorrerlas sin volver atrás en el navegador.

Una solicitud de reunión llega ahora como correo formateado a la casilla comercial, y el remitente recibe su confirmación en el idioma en que escribió.

Lo que aprendí

Un sitio bilingüe se rompe por la duplicación, no por la traducción. Mientras las rutas vivieron en el menú, en el cambio de idioma y en cada página, cada sección nueva costaba tres ediciones y producía al menos un enlace roto. Con una tabla única el idioma dejó de ser un caso especial.

La otra lección es comercial. El formulario no es un detalle de la página de contacto: es el único punto del sitio donde el visitante deja algo. Fue lo que más atención de seguridad recibió y lo único que justificó tener servidor.