Saltar al contenido
georgepuma.dev

proyectosronatello

Mini-caso · Cliente directo · 12 días a producción

Ronatello

Sitio de producción para una licorería de barrio recién abierta en Arequipa: promociones con vigencia, reservas con cupo y panel de administración propio. Del brief al despliegue en 12 días.

problema
Una licorería recién abierta necesita publicar promociones que caducan, tomar reservas sin pasarse del cupo y administrarlo todo desde un panel propio.
rol
Cliente directo: del brief al despliegue en 12 días, reutilizando el starter kit extraído de Cleo Spa. En producción.
alcance
24 rutas (9 públicas + panel de administración) · reglas de negocio en Postgres con RLS · CI que levanta un stack Supabase real.
resultado

12 días

brief → producción

24 rutas

9 públicas + panel admin

Next.js 16 · React 19 · TypeScript · Tailwind v4 · Supabase · Vitest · GitHub Actions

El producto, sin maquillaje

Tabla de promociones del panel: cada fila con el combo, precio, rango de vigencia, cupo y estado — vigente o finalizada — y acciones para editar y despublicar.
Promociones: vigencia con fechas y cupo a la vista. La finalizada sigue en la tabla — historial, no borrado.
Tabla de reservas: código, promoción, cliente con botones para llamar o abrir WhatsApp, entrega y estado; las vencidas muestran una nota de estado final que se conserva como historial.
Reservas: una vencida pasa a solo registro — se conserva como historial y el teléfono sigue visible por si hay que contactar al cliente.
Panel de inicio con cuatro tarjetas: reservas que esperan respuesta, promociones que cierran pronto, productos publicados en la web frente a los que no, y acceso al sitio público.
El panel abre con lo accionable: qué espera respuesta, qué cierra pronto y qué ve — o no ve — el cliente.

Tres decisiones que sostienen el resto

  1. Una promoción sabe cuándo vive

    Cada promoción lleva rango de vigencia y cupo, y el estado se lee de ahí: vigente o finalizada. Se puede despublicar antes de tiempo, pero la finalizada no desaparece — queda en la tabla como historial de lo que se ofreció.

  2. Una reserva vencida es un registro, no un pendiente

    Las reservas descuentan cupo de su promoción y vencen si nadie responde a tiempo. Una reserva vencida, entregada o cancelada pasa a estado final: se conserva como historial, ya no admite acciones, y el teléfono del cliente queda visible por si hay que contactarlo.

  3. Las reglas viven en Postgres, y el CI las prueba de verdad

    Las reglas de negocio viven en Postgres con RLS y el CI levanta un stack Supabase real — el mismo esqueleto de roles, RLS y CI extraído de Cleo Spa. Reutilizar decisiones ya discutidas una vez es lo que permitió ir del brief al despliegue en 12 días.

Lo que dejó

La prueba de que el starter kit extraído de Cleo Spa funciona: el mismo esqueleto de roles, RLS y CI, del brief a producción en 12 días. Lo que allá fue una extracción, aquí fue plazo.

La regla más delicada del sistema — que una reserva vencida devuelva su cupo — tiene un test en pgTAP que la cubre entera, y el CI todavía no lo ejecuta: un verde que no comprueba lo que más importa. Es un paso de workflow, y es el siguiente.