SpendSync

SpendSync es un producto de gestión de gastos compartidos para personas que viven o gastan juntas. Resuelve dos problemas de dinero distintos en un mismo sistema: cuentas de servicios recurrentes que se repiten cada mes, y gastos puntuales divididos entre un grupo. El producto está desplegado públicamente, tiene un modelo de suscripción de tres niveles cobrado por Stripe, y se opera como un servicio real y no como una demo.

Dividir dinero con otras personas falla de dos formas distintas, y la mayoría de herramientas solo resuelve una. Una cena puntual es un monto único dividido entre unas cuantas personas que estuvieron de acuerdo en estar ahí. La renta y los servicios son lo opuesto: el monto cambia cada mes, el mismo grupo se repite indefinidamente, y alguien tiene que acordarse de quién ya pagó este ciclo.

Tratar ambos como el mismo objeto produce un esquema que está mal para al menos uno de los dos. Tratarlos como cosas sin relación produce dos productos atornillados entre sí, con dos bandejas de entrada, dos nociones de 'quién me debe' y ninguna vista compartida del mes de un hogar.

El producto está dirigido a personas que comparten costos recurrentes: compañeros de piso, parejas, familias y grupos pequeños que ya dividen dinero de manera informal por chat y terminan cada mes reconstruyendo quién pagó qué.

Los niveles de precio siguen esa realidad en vez de una métrica de uso abstracta. El plan gratuito permite transacciones personales ilimitadas pero solo una cuenta compartida activa, que alcanza para llevar tu propio gasto. Plus sube los límites compartidos y agrega exportación y proyección. Pro elimina los límites y agrega la liquidación de entrada y salida — el momento exacto en que un hogar de verdad necesita un balance limpio.

El esquema mantiene los dos problemas de dinero separados a nivel de tablas en lugar de forzar una sola abstracción sobre ambos.

Las cuentas de servicios son el lado recurrente. Una cuenta tiene renglones, participantes con un monto adeudado, invitaciones con estado de aceptada o rechazada, una bitácora de actividad, y una fila por ciclo mensual que registra quién pagó en ese mes específico. Una cuenta pasa por draft, pending_responses y finalized.

Las transacciones son el lado puntual: un registro tipificado (gasto, cuenta o ingreso) con recurrencia opcional, sus propios participantes que cargan tanto un estado de invitación como un estado de pago, y pagos por ciclo para el caso recurrente.

Una tabla aparte de friendships lleva el grafo social, para que una invitación pueda dirigirse a alguien que el usuario ya conoce, y una tabla de invitaciones por correo basada en token cubre a las personas que todavía no tienen cuenta.

La identidad está delegada a Amazon Cognito. El cliente inicia sesión con Amplify y recibe un JWT; cada ruta protegida del servidor verifica ese token contra las llaves públicas de Cognito antes de que corra un handler, y el sujeto verificado se convierte en la identidad de la petición. La base de datos de la aplicación nunca almacena una contraseña.

La regla que de verdad importa no es la autenticación sino el consentimiento. La fila de un participante existe en estado de invitación pending hasta que la persona invitada responde explícitamente. Los montos adeudados solo son reales una vez aceptados. La propiedad es explícita tanto en cuentas como en transacciones, así que las operaciones destructivas — finalizar, reabrir, iniciar un nuevo ciclo — se validan contra el dueño y no contra la membresía.

Dividir un monto entre personas casi nunca da exacto, y la aritmética de punto flotante lo empeora introduciendo un error que se acumula a lo largo de los ciclos. Por eso el esquema guarda un amount_owed explícito por participante en lugar de guardar un porcentaje y recalcular la parte en cada lectura: la división se decide una vez, se escribe, y nunca se vuelve a derivar.

Eso también vuelve significativa la bitácora. El balance de un participante es la suma de filas que efectivamente se escribieron, así que la bitácora de actividad y el balance siempre coinciden.

La API corre como un contenedor Docker en una instancia de AWS Lightsail detrás de Nginx, que termina TLS y hace proxy al puerto de la aplicación, de modo que el contenedor nunca queda expuesto directamente. El cliente React se compila y se sirve por AWS Amplify Hosting. Identidad, correo y pagos son servicios administrados de AWS y Stripe en lugar de componentes autoalojados.

La forma de esa decisión importa más que los servicios específicos: las partes que son caras de equivocar — identidad, entregabilidad de correo, manejo de tarjetas — están delegadas, y la parte que carga la lógica real del producto es la parte que se opera en casa.

SpendSync se vende como suscripción con un nivel gratuito. La compra pasa por Stripe Checkout, y a los suscriptores existentes se les envía al portal de facturación de Stripe para cambiar o cancelar su plan, de manera que la aplicación nunca maneja datos de tarjeta ni construye sus propias pantallas de facturación.

Los límites entre niveles están trazados donde el producto cuesta dinero operarlo y donde empieza a crear valor real para un hogar: cuentas compartidas, amigos, profundidad de historial y exportación.

El trabajo difícil no fue dividir un monto. Fue el hecho de que una cuenta compartida nunca está terminada cuando el software cree que lo está. Un ciclo se cierra y luego llega un pago tardío. Alguien acepta una invitación dos semanas después que el resto del grupo. Un participante paga una parte de lo que debe y el resto el mes siguiente. Alguien se muda a mitad de ciclo.

Cada una de esas es una transición de estado que tiene que ser legal sin corromper el historial que la precede. Por eso el esquema lleva el pago con granularidad de ciclo en vez de como un booleano en el participante, por eso las cuentas se pueden reabrir y no solo finalizar, y por eso la bitácora de actividad es una tabla y no una vista derivada: una vez que una cuenta puede moverse hacia atrás, el único registro confiable de lo que pasó es el que se escribió en el momento.