What it is

Cuadremos (Colombian for “let’s settle up”) is a REST API for splitting shared expenses with friends, family, roommates or travel buddies. You create a group, log who paid for what, and the API works out who owes whom and the fewest payments needed to square things up.

If you’ve used Splitwise or Tricount, the idea will feel familiar.

Why I’m building it

Day to day I work mostly with Go and TypeScript. I picked Java and Spring Boot for this one on purpose: I learn a stack fastest by shipping something real with it, not by following tutorials.

So it gets treated like a product, not an exercise. Layered architecture, security, automated tests, versioned database migrations and continuous integration were all in place before the first feature was finished.

How I approach it

• Security from the start, not bolted on. Passwords are hashed with the algorithm OWASP currently recommends, sessions are short-lived and stateless, and a failed login never reveals whether an account exists.
• Permissions people can reason about. Every group has members, admins and exactly one owner. That last rule is guaranteed by the data model itself rather than by code that could forget to check.
• Shared money history is never deleted. A group gets archived instead: still readable, closed to changes.
• The database is versioned like code. Every schema change is a reviewed migration, so any environment can be rebuilt the same way.
• Checked on every push. Unit and integration tests run automatically before anything is merged.

Where it stands

Accounts, login, groups, roles, permissions, ownership transfer and archiving are done. Invitations come next, followed by the expenses themselves (equal, exact and percentage splits that always add up to the cent), balances, and settle-up suggestions that minimise the number of payments.

The repository has the full technical picture: architecture, data model, API reference and the reasoning behind each design decision.

Qué es

Cuadremos es una API REST para dividir gastos entre amigos, familia, roommates o compañeros de viaje. Creas un grupo, registras quién pagó qué, y la API calcula quién le debe a quién y cuáles son los pagos mínimos para quedar a paz y salvo.

Si has usado apps como Splitwise o Tricount, la idea te resultará familiar.

Por qué lo estoy construyendo

En el día a día trabajo sobre todo con Go y TypeScript. Para este proyecto elegí Java y Spring Boot a propósito: la forma más rápida en que aprendo un stack es entregando algo real con él, no siguiendo tutoriales.

Por eso lo trato como un producto y no como un ejercicio. La arquitectura por capas, la seguridad, las pruebas automatizadas, las migraciones versionadas de base de datos y la integración continua estaban listas antes de terminar la primera funcionalidad.

Cómo lo abordo

• Seguridad desde el inicio, no al final. Las contraseñas se protegen con el algoritmo que OWASP recomienda hoy, las sesiones son cortas y sin estado, y un login fallido nunca revela si la cuenta existe.
• Permisos fáciles de razonar. Cada grupo tiene miembros, admins y exactamente un dueño. Esa última regla la garantiza el propio modelo de datos, no un código que podría olvidar revisarla.
• El historial de plata compartida nunca se borra. Un grupo se archiva: se puede seguir consultando, pero ya no admite cambios.
• La base de datos se versiona como el código. Cada cambio de esquema es una migración revisada, así que cualquier entorno se reconstruye igual.
• Verificado en cada push. Las pruebas unitarias y de integración corren solas antes de integrar cualquier cambio.

En qué va

Cuentas, login, grupos, roles, permisos, traspaso de propiedad y archivado ya están listos. Siguen las invitaciones y después los gastos como tal (división igual, exacta y por porcentaje, que siempre cuadra al centavo), los balances y las sugerencias de pago con el mínimo de transferencias.

En el repositorio está todo el detalle técnico: arquitectura, modelo de datos, referencia de la API y el porqué de cada decisión de diseño.