Ooverlap

Una plataforma social que resuelve la pregunta más vieja de cualquier grupo: ¿cuándo nos vemos? Ooverlap calcula automáticamente el hueco común del grupo a partir de la disponibilidad que cada uno marca.

Problema Coordinar a un grupo es un problema de fricción, no de calendario.

Todos hemos vivido el mismo hilo interminable: veinte mensajes, cinco disponibilidades distintas y una quedada que nunca cuaja. La coordinación no falla por falta de calendarios. Falla porque coordinar cuesta esfuerzo repetido, y ese esfuerzo se abandona.

Enfoque Que marcar disponibilidad se haga una vez, no cada vez.

La hipótesis: si cada persona marca su disponibilidad (puntual o como patrón semanal recurrente) una sola vez, y el sistema cruza automáticamente la de todo el grupo, coordinar deja de ser una negociación y pasa a ser una consulta. No hay integración con calendarios externos — el usuario marca sus franjas libres/no disponibles directamente en la app, y el patrón recurrente evita tener que repetirlo cada semana.

La decisión de diseño central fue separar dos cosas: la disponibilidad (global del usuario, no por grupo) y el cálculo de overlap (agregado por grupo bajo demanda). Eso permite que un usuario marque su disponibilidad una vez y la reutilice en todos sus grupos.

Proceso De MVP a producto en producción, en fases.

Auth y perfiles — registro, sesión, perfil de usuario sobre Supabase Auth. Grupos e invitaciones — creación de grupos, membresías, tokens de invitación. Motor de disponibilidad — el núcleo: grid de horarios (mañana/tarde/noche), patrón recurrente semanal, y las funciones SQL que calculan la disponibilidad efectiva y el solapamiento del grupo. Quedadas y gastos — organizar quedadas sobre los huecos encontrados, confirmar asistencia, repartir gastos compartidos del grupo (estilo Tricount). Notificaciones y app nativa — notificaciones in-app y push nativas (Firebase), y una app Android que envuelve la web. Arquitectura Un monolito Next.js, con la lógica de overlap en el propio Postgres.

Next.js (App Router) con Server Components y Server Actions. No hay microservicios ni webhooks de sincronización: toda la app corre en un único despliegue sobre Vercel. El cálculo de disponibilidad y solapamiento vive como funciones SQL (effective_availability, group_overlap) dentro del mismo Postgres de Supabase, invocadas por RPC — deliberadamente para no duplicar esa lógica en TypeScript. Row Level Security en toda tabla con datos de usuario.

Frontend: Next.js · React · Server Components/Actions Backend: Supabase (Postgres, Auth) · Drizzle ORM Motor: funciones SQL de disponibilidad efectiva y solapamiento, sin servicio separado Retos El reto no fue conectar calendarios — fue no tener que hacerlo.

Al no integrar con Google Calendar ni similares, todo el peso de "no depender de nadie más" cae en que marcar disponibilidad sea rápido y que no haya que repetirlo: de ahí el patrón recurrente semanal y la disponibilidad global reutilizable entre grupos. El reto real fue de producto, no técnico: decidir qué parte de la coordinación automatizar (el cálculo) y qué parte dejar manual mínima (marcar franjas), sin pretender resolver algo que no se ha construido (sincronización automática de agendas).

Resultados Sin métricas de uso instrumentadas todavía — no hay analytics en la app.

MVP en producción con usuarios reales activos. No existe un panel de analíticas que mida mensajes ahorrados, tiempo hasta encontrar hueco, o planes cerrados frente a coordinación manual — cualquier cifra de ese tipo sería inventada. Si quieres esas métricas, es una feature pendiente (instrumentación + dashboard), no un dato que ya exista.

Aprendizajes Automatizar el cálculo no es lo mismo que eliminar el esfuerzo de entrada.

Ooverlap redujo la fricción del cálculo (nadie negocia manualmente el hueco común) pero no eliminó la fricción de entrada (alguien tiene que marcar su disponibilidad). El patrón recurrente fue el intento de cerrar esa brecha sin construir integración con calendarios externos, que sigue siendo la pieza que falta si se quiere fricción cero de verdad.