OrganizaBoda

OrganizaBoda es un producto para la parte de una boda que consiste en invitar a gente y enterarse de quién viene. Se manda una invitación, cada invitado entra desde su propio enlace y responde; quien organiza ve el recuento actualizado sin ir persiguiendo respuestas por WhatsApp.

Es producto propio: lo construimos nosotros y lo operamos nosotros. Su oferta pública hoy son invitaciones, invitados y respuestas. Tiene dentro otras superficies —presupuesto, proveedores, documentos, inspiración— que no forman parte de esa oferta y que el propio producto marca como futuras. Esa distinción no es un descuido de la web: es una decisión, y más abajo se explica.

Visto desde fuera, confirmar asistencia a una boda parece un campo de sí o no. Basta abrir una hoja de cálculo para que deje de parecerlo.

El primer desajuste es de unidad. La invitación no se manda a personas, se manda a casas: «Ana y Javier», «la familia Pérez», «Marta +1». Pero las respuestas no llegan por casa. Llegan por persona, porque el menú, las alergias y el autobús son de cada uno. La cosa que envías y la cosa que responde no son la misma cosa, y una columna por invitado no tiene dónde guardar esa diferencia.

El segundo aparece con el transporte. Un autobús no es un sí: es una parada concreta, a una hora concreta, y una hora de vuelta que no todo el mundo elige igual —los que se van pronto y los que cierran la fiesta. Escrito en un párrafo de texto libre, eso se lee perfectamente y no sirve para nada más: no se puede contar cuánta gente sube en cada parada, ni exportar la lista para dársela a la empresa de autocares, ni cambiar una hora sin reescribir la frase que ya han leído todos los invitados.

Y el tercero es de propiedad del dato. Cada respuesta, cada parada y cada documento pertenece a una boda concreta y a las personas que la organizan. Eso no es una preferencia de diseño: es la condición para que el producto pueda existir con más de una boda dentro.

La decisión que ordena las demás fue separar la unidad de invitación de la persona invitada. Son dos objetos distintos: el grupo que recibe un enlace y cada individuo que responde dentro de él. Una vez separados, un grupo de cuatro puede tener cuatro menús, dos alergias y tres paradas de autobús distintas sin que nada de eso se pise.

Esa separación se introdujo sobre un producto que ya funcionaba con un enlace por invitado, así que el modelo anterior se mantuvo como camino de compatibilidad en lugar de sustituirlo de golpe. Cambiar el modelo de datos de algo que ya está en marcha es un problema de diseño, no sólo de base de datos: hay invitaciones enviadas que tienen que seguir abriéndose.

La segunda decisión fue no preguntar lo mismo en todas las bodas. Cada boda decide si recoge menú, si recoge alergias y si recoge transporte. Una boda sin autobús no debería enseñar a sus invitados una pregunta sobre autobuses, y una opción de menú es de esa boda, no del producto.

La tercera fue darle identidad propia a la logística. Una parada dejó de ser una frase y pasó a ser algo con nombre, hora de recogida y ubicación; las horas de vuelta, un conjunto propio de la boda. La respuesta de cada persona ya no describe su autobús: apunta a una parada concreta y a una vuelta concreta. Es la diferencia entre un texto que alguien lee y un dato que se puede contar, exportar y corregir.

La cuarta no se ve y sostiene todo lo demás: cada tabla cuelga de una boda, el acceso se comprueba por pertenencia a esa boda, y hay papeles distintos —quien organiza, su pareja, una wedding planner invitada, alguien que sólo mira—. Los archivos viven en almacenamiento privado, no en una URL que cualquiera pueda adivinar.

La aplicación está construida sobre React con TanStack Start y desplegada con renderizado en servidor; los datos, la autenticación y los archivos son Supabase. Toda la aplicación privada cuelga de la ruta de una boda concreta, de modo que el aislamiento no es una comprobación que alguien recuerda escribir: es la forma de la aplicación.

El cambio de transporte es el mejor ejemplo del criterio con el que se trabaja aquí. Se añadieron las paradas y las horas de vuelta como tablas nuevas, y se dejaron intactos los campos de texto libre que ya existían, que siguen apareciendo igual en las bodas que los usaban. La respuesta que ya se guardaba —«esta persona necesita autobús»— conservó su significado exacto y ganó dos referencias: a qué parada y a qué vuelta. Nada que estuviera publicado cambió de aspecto el día del despliegue.

Alrededor de eso hay trabajo que no se enseña en una captura: importación de invitados por CSV, búsqueda y filtros, recordatorios atados al grupo al que pertenecen, exportaciones para la logística, cobro por boda publicada y una consola interna para operar el producto. La seguridad se endureció en varias pasadas —permisos por papel, acceso al almacenamiento, permisos de ejecución de las funciones—, cada una en su propia migración.

La primera lección es que la parte difícil casi nunca es la pantalla. Es decidir qué objetos existen. Cuando la unidad que envías y la unidad que responde son distintas, ninguna cantidad de diseño de interfaz arregla un modelo que las trata como si fueran la misma.

La segunda es que el texto libre es barato de escribir y caro de operar. Una frase con la hora del autobús se redacta en diez segundos; contar cuánta gente sube en cada parada a partir de esa frase no se puede. Convertir texto en identidades cuesta más al principio y es lo que permite después contar, exportar y cambiar sin reescribir.

La tercera es que un producto en marcha se cambia por acumulación, no por sustitución. Lo que ya estaba enviado siguió funcionando mientras el modelo nuevo se ponía debajo.

Y la cuarta es sobre contención. Tener una pantalla construida no obliga a venderla. Sostener una función tiene un coste que se paga después, y esa es una decisión comercial tanto como técnica.

Todo esto se aplica igual fuera de una boda. Cualquier negocio con un proceso real —reservas que dependen de turnos, pedidos que dependen de stock, expedientes que dependen de quién puede verlos— tiene el mismo problema debajo, y no se resuelve con una web de cinco páginas.