Diseñar BillParty offline-first: las restricciones como features

BillParty es una app pequeña para repartir gastos de grupo — un viaje, un apartamento, una salida. No tiene servidor, ni login, ni sincronización en la nube. Suena como una lista de features que faltan. En realidad es justo el punto.

La restricción

Quería BillParty en F-Droid, lo que significa software totalmente libre y, para esta app, nada de red. Sin Firebase, sin analytics, sin llamadas al servidor de nadie. Al principio se lee como una limitación. Pero una restricción dura obliga a la claridad: si los datos nunca pueden salir del teléfono, muchas preguntas de diseño se responden solas.

Las restricciones aclaran

Sin backend no hay cuentas que crear — abres la app y la usas. Sin sincronización el estado vive en exactamente un lugar, el teléfono del organizador, así que no hay resolución de conflictos que agonizar. Compartir se vuelve una foto del estado — un resumen en texto o un código QR — en vez de un stream en vivo multi-dispositivo. Para saldar cuentas después de un viaje, una foto es exactamente lo correcto, y es privada por defecto porque los datos simplemente nunca viajan.

Lo que parecía "Splitwise pero peor" se convirtió en un producto genuinamente distinto: uno que funciona en modo avión y nunca le pide a nadie registrarse.

La arquitectura que cae por su propio peso

Sin red, el código interesante es todo lógica de dominio, así que ahí va la energía del diseño. El núcleo son funciones puras — repartir un monto, calcular balances, simplificar quién-le-paga-a-quién — con el dinero guardado como enteros para que la matemática sea exacta. SQLite queda en el borde como un detalle; el dominio no sabe ni le importa que esté ahí.

La lección que sigo reaprendiendo: una restricción no es enemiga del buen diseño. Manejada con honestidad, es el diseño. Lo que no puedes hacer te dice en voz baja qué debería ser el producto.