SpendSync

SpendSync is a shared-expense management product for people who live or spend together. It handles two different money problems in one system: recurring service bills that repeat every month, and one-off expenses split across a group. The product is publicly deployed, has a three-tier subscription model billed through Stripe, and is operated as a real service rather than a demo.

Splitting money with other people fails in two different ways, and most tools only solve one of them. A one-off dinner is a single amount divided between a handful of people who all agreed to be there. Rent and utilities are the opposite: the amount changes every month, the same group repeats indefinitely, and somebody has to remember who has already paid this cycle.

Treating both as the same object produces a schema that is wrong for at least one of them. Treating them as unrelated produces two products bolted together, with two inboxes, two notions of 'who owes me', and no shared view of a household's month.

The product is aimed at people who share recurring costs: roommates, couples, families and small groups who already split money informally over chat and end each month reconstructing who paid what.

The pricing tiers follow that reality rather than an abstract usage metric. The free tier allows unlimited personal transactions but only one active shared bill, which is enough to track your own spending. Plus raises the shared limits and adds export and forecasting. Pro removes the limits and adds move-in and move-out settlement — the specific moment when a household actually needs a clean balance.

The schema keeps the two money problems separate at the table level instead of forcing one abstraction over both.

Service bills are the recurring side. A bill owns line items, participants with an amount owed, invitations with an accepted or rejected state, an activity log, and a row per monthly cycle recording who has paid in that specific month. A bill moves through draft, pending_responses and finalized.

Transactions are the one-off side: a typed record (expense, bill or income) with an optional recurrence, its own participants each carrying both an invitation status and a payment status, and cycle payments for the recurring case.

A separate friendships table carries the social graph, so an invitation can address someone the user already knows, and a token-based email invitation table covers people who do not have an account yet.

Identity is delegated to Amazon Cognito. The client signs in through Amplify and receives a JWT; every protected route on the server verifies that token against the Cognito public keys before a handler runs, and the verified subject becomes the user identity for the request. The application database never stores a password.

The consequential rule is not authentication but consent. A participant row exists in a pending invitation state until the invited person explicitly responds. Amounts owed are only real once accepted. Ownership is explicit on both bills and transactions, so destructive operations — finalising, reopening, starting a new cycle — are checked against the owner rather than against membership.

Splitting an amount between people almost never divides evenly, and floating-point arithmetic makes that worse by introducing error that accumulates across cycles. The schema therefore stores an explicit amount_owed per participant rather than storing a percentage and recomputing the share on every read: the split is decided once, written down, and never re-derived.

That also makes the audit trail meaningful. A participant's balance is the sum of rows that were actually written, so the activity log and the balance always agree.

The API runs as a Docker container on an AWS Lightsail instance behind Nginx, which terminates TLS and proxies to the application port so the container is never directly exposed. The React client is built and served through AWS Amplify Hosting. Identity, email and payments are managed AWS and Stripe services rather than self-hosted components.

The shape of that choice matters more than the specific services: the parts that are expensive to get wrong — identity, mail deliverability, card handling — are delegated, and the part that carries the product's actual logic is the part that is self-operated.

SpendSync is sold as a subscription with a free tier. Purchase runs through Stripe Checkout, and existing subscribers are sent to the Stripe billing portal to change or cancel their plan, so the application never handles card details or builds its own billing screens.

The tier boundaries are drawn where the product costs money to run and where it starts creating real value for a household: shared bills, friends, history depth and export.

The difficult work was not splitting an amount. It was the fact that a shared bill is never finished when the software thinks it is. A cycle is closed and then a late payment arrives. Someone accepts an invitation two weeks after the rest of the group. A participant pays part of what they owe and the rest next month. Someone moves out mid-cycle.

Each of those is a state transition that has to be legal without corrupting the history that came before it. That is why the schema carries payment at cycle granularity rather than as a single boolean on the participant, why bills can be reopened rather than only finalised, and why the activity log is a table instead of a derived view: once a bill can move backwards, the only trustworthy record of what happened is the one that was written at the time.