Privacy

• Household Hub stores what housemates type into a shared ledger: names, bills, splits, settlements and meter readings, plus the email address and password you sign in with, and a record that you agreed to the terms of use and this policy.
• There is no analytics, no advertising and no tracking on this site. Nothing here is sold, and nothing is shared for marketing. The one script from another company is a security check from Cloudflare, and it runs only on the forms that create an account, sign you in or send you a sign in link, send a password reset, or change your password.
• Four companies receive data because the product runs on them: Supabase, which holds the database and the sign in; Vercel, which hosts the site; Resend, which delivers the two emails this app sends; and Cloudflare, which runs that security check. There is no fifth.
• Two cookies, both required to sign you in and show you the right household. There is nothing optional to agree to, so there is no consent banner.
• There is no column anywhere in this database that can hold a card number, a bank account number or a routing number.

Creating an account writes two things. The account itself is held by Supabase Auth rather than by this application. The record that you agreed to the terms is held by this application, in its own database.

Your email address

The address you sign in with. It is also where invitations, confirmations and password resets are sent.

Your password

Passed straight to Supabase Auth, which stores it hashed. No table in this application holds a password or a hash of one. A new password must be at least eight characters, with no rules about digits, symbols or case. Passwords set earlier, under Supabase’s default minimum of six, still work.

The state of the account

Whether the address has been confirmed, when the account was created, and when it was last used to sign in. That is Supabase Auth’s own record of the account, not something this app writes.

Your display name

The name housemates see. If you have never set one, the database derives a placeholder from the part of your address before the @ sign, and marks it as a guess so that it is never published on a share link.

Your agreement to the terms

Creating an account asks you to tick two boxes: that you agree to the Terms of Use, and that you have read this Privacy Policy. For each of the two, the database records the address the account had at the time, the date the document carried when you agreed (which is how the version is identified), the moment you agreed, and where: at sign up, or later inside the app. The database writes it itself at the moment you agree, and it cannot be edited or deleted from inside the product. You are not asked again. An account created before these boxes existed is asked once, inside the app, before it can create or join a household.

Sign in is by email and password. There is no sign in with Google, Apple or anything else today. A Google button exists in the source and is switched off; a test attached to this page fails if it is switched on without this section being rewritten first, because turning it on would add Google to the list of companies that receive your data.

The forms that create an account, sign you in, send a sign in link, send a password reset and change your password include a security check from Cloudflare. What it receives is set out under who else receives this data.

A household is the unit everything else hangs off. This is the whole of it, table by table.

The household

A name, a currency, an optional address typed into household settings, and three preferences: whether share links are allowed at all, how long a new share link lives by default, and whether settle up amounts are rounded to whole dollars when they are shown. The address is a free text field. Nothing reads it, validates it or sends it anywhere, and you never have to fill it in.

People

For each person on the ledger: a display name, a role (admin, member or viewer), a default share, whether they are active or removed, and, for anyone with an account or an open invitation, the email address they sign in with. Someone can be on a ledger as a name only, with no account and no address at all.

Bills

The amount, the date, a category, a description you write, who paid, which split method was used, and whether the bill is paid or still outstanding. A metered utility can also carry a usage figure and a unit. A bill can point at a payment method, and at a tag marking it as part of a bulk import.

Splits

For every bill, each person’s share input and the exact cents they were allocated. The allocations always sum to the bill.

Settlements

Who paid whom, how much, on what date, and an optional note you write. No money moves through this app. A settlement is a bookkeeping entry recording that a debt was squared somewhere else.

Meter readings

For a metered utility: the month, the usage figure, the unit and the cost.

Recurring bills and split profiles

The templates a household reuses month after month, and the named share allocations behind them.

Invitations

The address invited, the role offered, an expiry, and the token that appears in the invitation link.

Share links

The token, what the link is scoped to, when it expires, whether it has been revoked, and how many times it has been opened.

The audit log

Admins can see a record of the things that change a household: invitations, joins, removals, role changes, bills created and deleted, splits changed, settlements recorded, months closed, share links created and revoked, password changes and settings changes. Each entry records who did it, when, and a short summary.

Two of those fields are free text that you write: a bill’s description and a settlement’s note. Whatever you type goes into the database as typed. A bill description is never published on a share link, and that is exactly why.

A household can record how a bill was paid, so that “Connor sent it back on Venmo” and “it went on the house card” stop being the same row. A payment method is three things and no more: a label you choose, a kind (card, bank, Zelle, Venmo, cash or other), and, for a card or a bank only, the last four digits already printed on your statement.

The four digits exist so that a person can tell two cards apart on a screen. Nothing reads them, validates them, or transmits them anywhere.

There is no column in this database that can hold a full card number, a bank account number, a routing number, an expiry date, a security code, a billing address or a login. That is not a policy sitting on top of a field that could hold one: the field does not exist, and the four digit field is constrained by the database to exactly four digits so that a longer number cannot be pasted into it. Household Hub never connects to a bank, never initiates a payment and has no payment processor.

This is the part people are usually surprised by, so it is stated plainly.

• Everyone in the household. Every active member can read that household’s bills, splits, settlements, meter readings, payment method labels and member list, including the email addresses of the members who have one. A viewer can read but not write; a member can write; an admin can additionally see the audit log, manage share links, remove people, void records and permanently delete records that have already been voided.
• Nobody else with an account. A person with no membership row for your household reads zero rows of it. That is enforced by row level security inside Postgres, on every table, not by a check in the application.
• Anyone holding a live share link, which is the next section.
• The operator. Household Hub has an operator portal that reads across households, because somebody has to be able to answer whether the service is working. By default it shows counts, dates and names, and no amounts at all. Opening one household’s figures is a separate, deliberate act, and the database writes a log row naming which operator opened which household and when, before it returns a single number. An operator’s ordinary session is not privileged: they still read zero rows of a household they do not belong to.

Both are bearer credentials. The token in the address is the credential, which means anyone holding the address is holding the access. Treat the link the way you would treat what is on the other side of it.

A share link publishes the household name and currency, the period it covers, the total paid and how many bills that was, the total still outstanding and how many bills that was, per category totals split into paid and outstanding, and for each person their paid, owed, settlements sent and settlements received. It does not publish email addresses, internal identifiers, bill descriptions, settlement notes or payment methods, and anyone who has never chosen a display name appears as “Member 1”, “Member 2” and so on rather than under a name derived from their address.

• It is live, not a screenshot. Record a settle up and the next person to open the link sees the new figure.
• Every successful view is counted, and there is no way for a viewer to suppress the count. Admins can see it.
• It expires. A household picks the default life of a link, fourteen days out of the box, and the database will not let one live longer than ninety days: a longer expiry is cut back to ninety on the way in, and a row that somehow carried one would fail a check constraint.
• An admin can revoke it at any moment, and turning sharing off for the household kills every live link at once. Revoking keeps the row, so the household keeps the record that the link existed and how often it was opened.
• The page is served with instructions not to index, archive or cache it, and with no referrer. Link preview bots are allowed to fetch it on purpose, so that the card unfurls when the link is pasted into a chat. That card shows the totals. It is the point of the feature and it is worth knowing before you paste.

An invitation link shows the household name, the address that was invited, the role offered and the expiry to anyone who opens it, before they sign in. Only the invited address can actually accept it.

Two cookies. Both are required for the app to work at all.

The Supabase Auth session cookie

Set when you sign in, cleared when you sign out. It carries your session, which is what keeps you signed in between pages. Its name is derived from the Supabase project this site runs on.

hh_active_household

Remembers which household you had open, so that a person in two households does not land in the wrong one. It holds one identifier, is HTTP only, is SameSite Lax, is secure in production and lasts a year. It is a preference and never a credential: every page re-checks it against the households you actually belong to and ignores it if it does not match.

Your light or dark preference is kept in the browser’s local storage under hh-theme. It is not a cookie, it is never sent to the server, and it never leaves your browser.

This site sets nothing else. No advertising cookie, no measurement cookie, and no cookie from anyone else for either purpose.

The one thing on this site’s pages that comes from another company is the security check on the account forms. It draws a frame served by Cloudflare, and whatever Cloudflare keeps in your browser for it, to tell a person from a bot, is Cloudflare’s: this site does not set it and does not read it. Cloudflare describes it in its Turnstile privacy addendum.

That is why there is no consent banner on this site: a banner asking you to accept the cookie that signs you in, or the check that keeps bots off the sign in forms, would be theatre, and there is nothing else to ask about. If that ever changes, the banner and this paragraph arrive together.

Four companies, each doing one job the product relies on, and each receiving something specific.

Supabase

The Postgres database and the authentication. Everything described on this page lives there. Supabase also sends the account emails, confirming a new address and resetting a password, through the mail transport configured on the project.

Vercel

The host. It runs this site’s server code, so every request passes through it: the address of the page you asked for, your IP address and your browser’s user agent, in the ordinary way of any web host. One consequence is worth spelling out. A share link carries its token in the address, so that token appears in the host’s record of the request.

Resend

Transactional email. It receives only the messages this application sends, of which there are two: an invitation to join a household, and the note telling someone that their name is already on a household’s ledger. Each carries the recipient’s address, the inviter’s display name, the household name, the role, the link and the address to sign in with. Nothing else is sent through it. If a deployment has no Resend key, no message is sent at all and the link still works.

Cloudflare

The security check, Cloudflare Turnstile, on four forms and nowhere else: creating an account; signing in, whether with a password or by asking for a sign in link; asking for a password reset; and changing your password on your account page. It is there to stop automated scripts from creating accounts, guessing passwords and sending mail to people who never asked for it. On those forms your browser loads a script from challenges.cloudflare.com. That script sends Cloudflare your IP address and signals from your browser that it uses to tell a person from a bot, together with the address of the page it is running on, the address of the page you came from, and a description of how the form is built: its fields, labels and buttons, not what you type into them. If you reached the sign in or create account page from an invitation, that page address contains the invitation link. This site does not give Cloudflare your email address or your password. Most people never see a challenge: the check finishes by itself and hands the form a token that works once, which this site passes to Supabase, and Supabase asks Cloudflare whether it is genuine. If you go on from one of those forms to another page without reloading, the script stays loaded in the tab with nothing to check. Cloudflare sets out what it does with this in its Turnstile privacy addendum. A copy of this site that has not been given a Turnstile key loads nothing from Cloudflare at all.

There is no fifth. The entire dependency list of this application is @base-ui/react, @supabase/ssr, @supabase/supabase-js, class-variance-authority, clsx, lucide-react, next, react, react-dom, recharts, tailwind-merge, tw-animate-css and zod. No analytics package, no error reporter, no session recorder, no advertising tag, no chat widget. A test attached to this page fails if that list grows, so the sentence you are reading cannot quietly stop being true.

Cloudflare’s script is not on that list because it is not installed with the app: the security check loads it from Cloudflare, on those four forms. A second test fails if any other file in the app starts loading a script, or if the check appears on a form this page does not name.

• Nothing is sold, rented or shared for advertising. There is no advertising on this product and no plan for any.
• There is no profiling, no scoring, and no automated decision made about you.
• Nothing is trained on your ledger.
• Apart from Cloudflare’s security check on the four account forms, no page on this site loads a script, a stylesheet, a font or an image from another company. The typefaces are downloaded when the site is built and served from this site, so your browser makes no request to Google in order to read this page, and this page loads nothing from Cloudflare.
• Pages are rendered on the server, so your browser never queries the database directly.

Money records are not erased by accident, and the two ways a record can end are deliberately different.

• Voiding is the ordinary correction. A bill or settlement that was wrong keeps its row, takes no further part in any balance, and records who voided it, when, and the reason they gave. A void can be undone.
• Permanent deletionis a second, separate act. It is available only to an admin, and only on a record that has already been voided or archived, so one click can never destroy a money record. The live row genuinely goes: out of every list, every total, every export and every share link. Before it goes, the database copies the whole row and everything attached to it into a table of tombstones, together with the reason the admin gave and who they were. That table is admin only, and the household’s own admins can read it at the foot of the audit log in settings: what was deleted, when, by whom, and the reason they gave. It exists so that the permanent deletion of money can still be accounted for afterwards, by the household and not only by the operator.
• Removing a person from a household marks them removed. Their name stays on the bills they were part of, because taking it off would silently change everyone else’s balance.

Apart from share links and invitations, which expire on their own, nothing expires automatically. A household’s data is kept for as long as the household keeps it. There is no retention schedule on this page because there is not one in the product, and writing a number here that nothing enforces would be a worse answer than this one.

Out. Signed in, the Insights page exports the household’s figures as a CSV, built from the same numbers the page itself shows.

Removed. There is no button in the app today that deletes an account or a household. Write to householdhub@matadortechnology.com and ask, naming the account and the household, and the operator will remove it by hand. Saying that is better than showing you a button that does not exist.

Deleting an account removes the account: the email address and password you sign in with, and every session signed in with them. It does not take you off the ledgers you were part of, because other people’s balances are made of them. On each household you belonged to, you stay on the member list under the name you had there, as a person with no account, and every bill, split and settlement you were part of stays exactly as it was. If you were an admin there, you stay on as a member. The household also keeps what it recorded about you: any email address on its member list, and its audit log, whose entries are no longer linked to any account.

The record that you agreed to the Terms of Use and the Privacy Policy is kept as well: the address, which version of each document, when, and where you agreed, no longer linked to any account. It is the evidence of what was agreed while the account existed, which is why deleting the account does not delete it. If the same address signs up again, that is a new account with a record of its own.

Three things are worth knowing before you ask.

• If you are the only admin of a household that other people still sign in to, one of them has to be made an admin before your account can be deleted, so that the household is not left with nobody able to run it.
• A household is shared. Removing one takes everyone on it with it, so it is not a decision one housemate makes quietly.
• Your name on a bill is part of somebody else’s arithmetic. It is removed by removing the record, not by editing you out of a total that then stops adding up.

The date at the top changes when the words do. There is no mailing list and no notification, so that date is the only signal. This page changes when the code changes, which is the only reason it should.

A privacy policy is easy to pad with paragraphs a product has not actually set up to honour. This one leaves them out instead.

There is no company registration or postal address printed here, no governing law, no dispute venue, no data protection officer, no certification, and no claim to comply with any particular privacy regime. Those are real things a real deployment needs, and they are being worked on with somebody qualified to write them. Until they exist, they are not going to be asserted here.

What this page does claim is narrow and checkable: it is an accurate description of what the code stores, what it sets, and what it sends.

Write to householdhub@matadortechnology.com. That is the address every email from this product is sent from, and the address to use for a question about this page, a request for your data, or anything that looks wrong.

The companion page is the terms of use, which covers what the product is, what it is not, and what it does not promise.