Carlos Aburto

Agenda clínica

Producto propio. Sistema de agendamiento para clínicas y consultas: el paciente reserva solo en la página de la clínica, la recepción lleva el día y cobra en el mesón, y a fin de mes están los números.

Lo que hice

• Multi-clínica desde el primer día: cada una con su subdominio, sus perfiles y su propia cuenta de cobro. Toda consulta filtra por establecimiento, incluso cuando busca por id; la reescritura del proxy es enrutamiento y no autoriza nada.
• Permisos por capacidad y no por rol. Los perfiles los arma cada clínica agrupando menús, así que crear uno nuevo no obliga a tocar código.
• Bitácora escrita en la misma transacción que el cambio, incluidas las consultas a la ficha de un paciente: son datos sensibles de salud y alguien tiene que poder responder quién los miró. La tabla es de sólo agregado.
• Los bloques de agenda se generan por tramos y son inmutables una vez que tienen cita. Acortar el periodo de una agenda sólo apaga bloques libres: una hora tomada no puede quedar fuera de su propia agenda.
• El pago va con el código de comercio de cada clínica: el dinero no pasa por mí.
• Nada se borra: los bloques se apagan y las citas viven canceladas, o los reportes dejan de cuadrar.

• Next.js
• TypeScript
• PostgreSQL
• Drizzle
• Vercel
• Webpay

carlos@cordillera.cl · clave demo-cordillera

Club de Montaña Collipulli

Sistema de gestión completo para un club de montaña: socios, cuotas, préstamos de equipo, salidas, reuniones con acta y asistencia, y el sitio público del club. Reescritura de un sistema PHP anterior.

Lo que hice

• Los montos de cuota se copian y no se referencian: cada cuota guarda lo que correspondía ese año, así que subir la cuota no reescribe el pasado.
• Los choques de fecha en los préstamos se resuelven bloqueando las filas de equipo con `select … for update` antes de buscar el choque. Sin eso, dos solicitudes simultáneas pasaban las dos porque cada una leía antes de que la otra escribiera.
• La disponibilidad de un equipo se deduce de sus préstamos y no de una columna de estado: la pregunta real nunca es «¿está afuera ahora?», es «¿está libre del 12 al 15?».
• Los datos de salud viven en su propia tabla y no en la de usuarios, para que ningún `select` los arrastre sin que nadie lo decida, y se leen con una capacidad aparte de la de ver socios.
• El token de sesión lleva de qué despliegue viene, así que la cookie de la demostración —cuya clave está impresa en pantalla— no sirve en el club.
• El sitio público se alimenta del mismo sistema: las fotos y los relatos de cada salida se publican solos.

• Next.js
• TypeScript
• PostgreSQL
• Drizzle
• Vercel Blob

admin@demo.cl · clave demo2026

Arawka Climbing Holds

Tienda en Shopify para una fábrica de macros y volúmenes de escalada que le vende a gimnasios y a personas al mismo tiempo.

Lo que hice

• Tema propio escrito desde cero, no una plantilla comprada: portada, producto, familia, catálogo, página, carro, búsqueda y 404.
• Carrito y cotización conviviendo en la misma ficha, porque no se le vende igual a quien compra una pieza suelta que a un gimnasio que equipa una sala.
• Las fichas técnicas viven como metacampos y no como texto dentro de la descripción, así que se pueden filtrar y ordenar.
• Bilingüe, con las tipografías alojadas en el tema y sin depender de Google.
• Un validador propio que revisa schemas, referencias entre secciones, balance de etiquetas Liquid y paridad de traducciones sin necesitar la CLI de Shopify.

• Shopify
• Liquid
• JavaScript
• Node