SettleUp

El Problema

Cuando tres personas pagan cosas compartidas — alquiler, súper, cenas — el saldo real se pierde en una maraña de Bizums. La pregunta “¿quién le debe a quién?” deja de tener respuesta clara al cabo de dos semanas.

La Decisión

El saldo se calcula, no se guarda. Cada vez que abres un grupo, cuatro queries en paralelo (Promise.all) suman lo que pagaste, lo que debías y los pagos confirmados. El resultado vive en el cliente mientras lo miras y desaparece. Si un dato cambia, se recalcula desde la fuente. Cero riesgo de inconsistencia entre el balance cacheado y la realidad.

Solo el payer puede cancelar un gasto. No por autoritarismo, sino porque un gasto es un acto contable: registrarlo dos veces o anularlo sin contexto rompe el cuaderno.

El algoritmo voraz garantiza N-1 transferencias como máximo. Empareja al mayor deudor con el mayor acreedor y va cuadrando. Es la misma cota que usa Splitwise — peor caso posible con deuda neta.

Lo Que Hace El Cuaderno

La estética no es piel. Cada elemento codifica estado:

• El sello Liquidado sobre una cuenta saldada es la confirmación visual de que el balance es 0.
• Los números de serie (+ 001, → 002) dan el orden de creación del grupo, no son decoración.
• El papel con textura reduce el cansancio en sesiones largas de un admin mirando cuentas.

Tiempo real dual: Socket.IO en local con salas por grupo, polling de 15s en producción. La UI no sabe cuál está usando — mismo hook, misma invalidación de queries.

Auth con Better Auth + cookies de sesión de 7 días. Password hasheado, sesión refrescable una vez al día. Cero dependencias de OAuth.