El sitio web de Porcelain Tech Studio

El reto

Porcelain Tech Studio abrió sin portafolio. Un estudio que vende sitios web, apps y Mini Programas de WeChat no puede presentarse con promesas, así que el primer proyecto tenía que ser nuestro propio sitio — y tenía que resistir el mismo escrutinio que les pedimos a los clientes que apliquen sobre nosotros.

Tres restricciones le dieron forma. Tenía que funcionar en inglés, chino y español, y cada idioma debía leerse como si se hubiera escrito primero, no traducido al final. Tenía que volver medibles nuestras propias promesas de servicio: “respondemos en un día hábil” no significa nada si el tiempo de respuesta no es un número que alguien pueda consultar. Y tenía que ser la primera implementación real de la base técnica que pensamos reutilizar — Next.js, FastAPI, PostgreSQL — no una página de marketing desechable.

Lo que construimos

Cinco pestañas — Inicio, Proyectos, Precios, Equipo y Contacto — completamente localizadas en tres idiomas a partir de un solo modelo de contenido, de modo que agregar una página o un idioma nuevo es un cambio de contenido, no una reconstrucción. El lenguaje visual es moderno y sin bordes: la tipografía, el espaciado y el color cargan con la estructura en lugar de las cajas y las líneas.

El flujo de prospectos trata a la base de datos como la fuente de verdad. Cada envío se escribe primero en Postgres y el correo es solo una notificación. Si el proveedor de correo se cae, el prospecto sigue existiendo y sigue apareciendo en la bandeja de entrada.

• El límite de solicitudes vive en Postgres, no en la memoria del proceso. Las instancias serverless no comparten memoria, así que un contador en memoria es un contador por instancia — es decir, ningún límite real.
• El spam lo absorbe un campo honeypot en lugar de un CAPTCHA, así los visitantes reales nunca tienen que demostrar que son humanos.
• Una bandeja de administración registra el tiempo de primera respuesta de cada consulta, lo que convierte el SLA de 24 horas en algo que reportamos en lugar de afirmar.
• La analítica y el monitoreo de errores entraron en operación desde el primer día, no después del primer incidente.

El backend expone un solo contrato de API. Hoy lo consume el cliente web; una app de iOS, una app de Android o un Mini Programa pueden consumir los mismos endpoints sin necesidad de un segundo backend.

Resultado

El sitio se publica en tres idiomas con paridad completa en las cinco pestañas. El rendimiento fue una restricción de construcción y no una limpieza posterior al lanzamiento: un presupuesto de LCP por debajo de 2.5 segundos en móvil y una meta de Lighthouse de 95+, verificados antes de integrar los cambios y no después de los reclamos.

Y lo más útil: ahora es la implementación de referencia. Cada decisión de stack que se tomó aquí — el contrato de API compartido, el límite de solicitudes respaldado por la base de datos, el modelo de localización, la configuración de monitoreo — es el punto de partida para el próximo proyecto de cliente, y ya está probada en producción en un sitio que es nuestro.