ARKA: un configurador y un checkout de verdad en una sola página
ARKA es un objeto de nogal tallado que sostiene esferas macizas de 50 mm, hecho por encargo en una primera serie de doce. Urbano DX diseñó el producto, construyó la página y gestiona los pedidos. Cada decisión del comprador cambia la ficha técnica y el precio delante de él, y una API pequeña vuelve a comprobar toda la configuración, incluido el país de envío, antes de pedirle a Stripe una página de pago.
Abrir ARKA
La página abre con una sola forma y una sola afirmación, y el render se etiqueta como render
Tres decisiones (número de esferas, forma y material) con la masa y el precio recalculados en cada cambio
La gama: nueve formas, cada una con sus dimensiones, su masa y el trabajo de taller que hay detrás del precio
La tabla de especificaciones y el formulario de reserva, ambos generados desde la misma fuente de verdadQué es
Una sola página que vende un objeto físico. Nueve formas, tres cantidades de esferas, cuatro opciones de material y un grabado opcional, todo por encargo en una primera serie de doce y con envío en seis semanas. Las imágenes son renders y no fotografías, y la página lo dice junto a cada imagen en lugar de esperar a que nadie pregunte.
- Nueve formas, desde una pieza alargada y plana hasta una escultura vertical
- Esferas de cobre, acero, cerámica o un juego mixto
- Ficha técnica en vivo: medidas, masa por esfera y masa total
- Cada imagen se abre a pantalla completa y gira sobre fotogramas renderizados
Qué se construyó
Una página estática prerenderizada delante de un servicio pequeño en FastAPI. El catálogo es una única fuente de verdad: las masas se calculan a partir de la densidad del material en vez de escribirse a mano, el servidor replica solo lo que necesita validar y un test tumba la build en cuanto los dos dejan de coincidir. Al reservar, la configuración se envía a la API, que vuelve a comprobar la forma, el material, el grabado y el país de envío, crea la Checkout Session de Stripe con esa configuración adjunta y avisa al taller por correo. El webhook que confirma el pago es idempotente, así que un reintento de Stripe no puede generar un segundo pedido.
- Configurador con masa y precio en vivo, sin recargar la página
- Validación en servidor de cada combinación antes de cobrar
- Checkout Sessions de Stripe con la configuración en los metadatos
- Webhook de pago idempotente y aviso por correo al taller
- Stack: Vite, React, TypeScript, FastAPI, Stripe, nginx
Qué demuestra
Aquí está la diferencia entre un enlace de pago y vender de verdad. Un enlace de pago no puede rechazar un país al que no se envía, no puede mantener de acuerdo a la página y al cobro sobre qué se ha pedido, y no puede capturar al comprador antes del dinero. Llevar esas reglas al servidor es un día de trabajo que elimina toda una familia de incidencias, y el mismo patrón sirve igual para flujos de presupuesto, de reserva y de productos configurables de clientes.
- Las reglas del producto viven en el servidor, no en el botón
- Un catálogo desincronizado es una build rota, no una queja del cliente
- La página se lee y vende igual con JavaScript bloqueado
- Un mismo patrón para cualquier flujo de configurar y pagar