Privacy Policy

1. Data controller and scope of this policy

The data controller of Homeconomy is José Antonio Jiménez, who can be contacted by email at jajimenez+homeconomy@gmail.com.

This policy covers the two sites from which Homeconomy is offered. They do different things, so throughout this document they are named differently:

• The public site (www.homeconomy.app): the presentation pages and these two legal documents. Read with no account and nothing to submit.
• The application (app.homeconomy.app): the actual household finance dashboard, where the user records their data.

When a section says "the application" it refers only to the second one, and when something applies to both it says "both sites". The distinction matters because almost everything that follows — the financial data, the encryption, the syncing — happens only in the application: there is nothing to store on the public site.

2. What data is processed and where it is stored

By default, Homeconomy has no server or database of its own: all the data the user enters (transactions, with their categories, subcategories and tags; scheduled transactions and templates; projects and their budget; loans and their repayments; shared pots; ledgers and the transfers between them; and the people associated with any of these) is stored exclusively on the user's device, using IndexedDB (the browser's local storage mechanism). The owner of the application does not receive, access or store that data in any system of its own for as long as the user does not turn on the syncing described in section 3.

Alongside that data, the application stores in the browser's local storage (localStorage) a handful of technical preferences needed to work: the light or dark theme, whether syncing is on or paused, and, only if the user checks "Trust this device", the encryption password (see section 9). None of this is sent to any server. The cookie decision is stored separately, in a cookie described in section 7.

During the sign-up and sign-in processes, and only for as long as they last, the application may also store two temporary notes in that same local storage: a one-time random value that lets it check that the response from an external sign-in provider (section 3) corresponds to an attempt started on this same device, and a copy of the encryption key already protected with the password — the same material that may later be synced, never the key in the clear — so the device can be restored to how it was if sign-up is interrupted halfway through. Both are deleted when the process ends, and the first one expires on its own after fifteen minutes. Neither contains financial data nor identifies anyone.

Some of these notes may include third-party data: the name, relationship and notes of the people with whom the user shares loans, pots or expenses. These get exactly the same treatment as everything else — they are stored on the device and, if syncing is turned on, travel encrypted — and are not used for any purpose other than showing them to the user themself. Nor are they shared with anyone else, with one exception that the user alone decides: when a pot is shared, the names and emojis of the people in the user's directory who are part of it, and the email address used to invite each person, are seen by the other people with access to that pot (see "Sharing a pot" in section 3). So long as the use is purely personal and household, it falls outside the scope of GDPR (Article 2.2.c); sharing a pot with specific people from the user's own circle — which is all the application allows, since only people who are already part of the pot can be invited — should in principle remain compatible with that household character, although if the use went beyond it the assessment would be different, and that cannot be taken for granted here. In any case, it is the user who decides what they record about other people and whom they share it with, and who is responsible for it.

Since no data is transmitted to any server in that default mode, the owner does not carry out any processing of the personal data the user enters in the application: such processing happens only locally, under the user's own exclusive control. The sole exception is the suggestion box described in section 10, which the user decides whether or not to use and which sends the owner only what they write in that form, never their financial data.

None of the above happens on the public site: there is no account to create, no form to fill in, no financial data to enter, and nothing is stored in the browser beyond the cookie that remembers the cookie decision (section 7). Anyone who only reads the presentation pages leaves no more of a trace than the aggregated analytics described in that same section.

3. Optional syncing between devices and shared pots (Dexie Cloud)

The application offers, on an optional basis and off by default, the ability to sync data between several devices belonging to the same user and, if the user chooses, to share a pot with other people (see "Sharing a pot" below), through the Dexie Cloud service, operated by Awarica AB, based in Sweden (European Economic Area). This feature only turns on if the user expressly presses one of the sign-in buttons ("Log in" or "Sign up") and completes the process; until they do, nothing is sent or stored outside their device.

When logging in, the user enters their email address to receive a one-time code: that email is processed by Dexie Cloud/Awarica AB to manage the login (it is linked to an account identifier, and it also appears within the technical session credentials issued by that service); this processing is independent of the encryption of the financial content described below.

Signing in with an external provider. As an alternative to the email code, the user can choose to sign in with a Google account. In that case the browser is redirected to Google's pages, where identification takes place entirely under that company's own terms and privacy policy; Google then returns the verified email address to Dexie Cloud, which is treated the same as if it had been typed in by hand. Three things are worth knowing. First, the owner of the application does not receive any credential from that account: no password, and no access to any other Google service. Second, Google does learn that account was used to sign in to this application, and its servers are located in the United States. And third, this is entirely optional: signing in with the email code remains available and does not involve any external provider.

Signing in with an external provider changes nothing about the encryption described below: the financial content still travels encrypted with a key that only exists on the user's devices, and on a new device the encryption password is still needed to read it. The provider saves you the email code, not the password.

End-to-end encryption of the financial content (amounts, category and subcategory names, notes, tags) is mandatory as soon as syncing is turned on, not an option: the application requires setting an encryption password before syncing for the first time, and does not allow encryption to be turned off while syncing stays on. The key used to encrypt is generated and stays on the user's devices, protected by that password, which only they know: neither Dexie Cloud/Awarica AB nor the owner of the application can read that content. Shared pots also have a key of their own, explained under "Sharing a pot".

Even so, some metadata always travels unencrypted and is visible to Dexie Cloud/Awarica AB and, technically, to the owner as administrator of the sync project. These are what the application needs to index in order to work, and it is worth knowing exactly what they are:

• For each transaction: its date, its type (income/expense), whether it is confirmed or is an estimate, and the internal identifiers that link it to the scheduled item, template, project, loan or settlement it comes from.
• For transactions, scheduled items, templates, projects and loans: which ledger each one belongs to and, for a transfer, which two transactions make it up and which two ledgers it runs between, again via internal identifiers with no name.
• For scheduled transactions: how often they repeat, their next date, their end date if they have one, and the closing day for card settlements.
• For loans: the date, the direction of the debt (whether the user lent or borrowed) and which people are involved, via internal identifiers with no name; the same applies to repayments, and to who takes part in each shared pot.
• For people, projects, ledgers, categories and subcategories: their structure — what belongs under what, which sections each person appears in, what is still active and what is hidden — and the approximate number of items of each type.
• For shared pots: what is detailed under "Sharing a pot", below, which includes the email addresses of the people with access.

In other words: the server can see when there are entries, and how they relate to each other and to which people (always via internal identifiers, never by name; the exception being the email addresses of the people with access to a shared pot, described below), but not what they are about or how much they involve. The financial content itself — amounts, names of categories, subcategories, people, projects, loans, pots and ledgers, notes and tags — is never transmitted unencrypted while syncing is on.

Sharing a pot

A pot can be shared with other people. This is an optional feature that only the pot's owner — the person who created it, not to be confused with the owner of the application — can use, and it requires being signed in (syncing on) and account encryption to be turned on. Only people who are already part of the pot can be invited, one invitation per person.

How people are invited. The pot's owner types the email address that person uses to sign in to Homeconomy. The application does not send any email: the pot's owner passes the invited person a link, a code or a QR code themself, and can use their system's "Send the link" option to do so. The invited person needs an account with that email address, signed in and with encryption on; they open the link or enter the code, and can decline the invitation.

The link carries the pot's key. It sits in the fragment of the link (the part after the "#"), which the browser never sends to any server: it does not reach Dexie Cloud or Vercel's logs. That is exactly why anyone who has the link can read the pot. The channel the pot's owner uses to get it to the invited person (a messaging app, email, in person…) is their own choice and lies outside the application, so neither the application nor the owner of the application can guarantee its confidentiality.

Roles. Each person with access has one of two roles: "View only", which lets them see the pot and its accounts, or "Can add entries", which also lets them record expenses, contributions, donations and advances and open today's round. The pot's owner is the only one who changes the settings, invites people, removes people, changes their roles and deletes the pot.

Encryption. Each shared pot has a key of its own (256-bit AES-GCM), generated on the device of the pot's owner, which the server does not have: the server cannot read the pot's content. Every member keeps that key encrypted with the key of their own account. As the application itself warns, the server knows which email addresses are invited, but cannot read the pot.

What members see. Everyone with access sees the whole pot, with the names and emojis of its members exactly as they are in the directory of the pot's owner; who added each entry ("Added by…"), which is informational and is not guaranteed by the server; and the email addresses of the other people with access, and that of the pot's owner.

What stays unencrypted on Dexie Cloud because of sharing. In addition to what is already listed in this section:

• That the pot is shared and with which email addresses: one row per member with their email address, their role and the status of the invitation (accepted or declined, with the date and who invited).
• The pot owner's account.
• Which account wrote each row, and when.
• The number of entries, of contributions per round and of extensions per expense.
• An internal, pseudonymous identifier for each member, which links their contributions across rounds.
• That an account has access to a pot.

The name of the shared space that Dexie Cloud creates for the pot is always the same ("Homeconomy") and reveals nothing. Amounts, descriptions, names, notes and the pot's key are encrypted.

Removing someone. When the pot's owner removes someone, that person stops seeing the pot in their application and loses anything they had not yet uploaded. What they have already seen is not taken away from them, and the pot's key does not change: the application does not rotate it, so the link or code they received would open the pot again if they were ever invited back.

4. Legal basis and purpose

To the extent that the owner does not process the personal data the user enters in the application in the default local mode (transactions, budgets, etc.), no legal basis for processing applies on their part over that data under Article 6 of Regulation (EU) 2016/679 (GDPR) for as long as syncing is not turned on. Its sole purpose, in that mode, is to provide the user themself, locally, with the household finance functionality.

If the user turns on syncing (section 3), the legal basis for that processing — sending the email address to Dexie Cloud/Awarica AB for login, and sending the financial data, always encrypted — is the user's consent (Article 6.1.a GDPR), given through the explicit act of signing in. It can be withdrawn at any time by signing out using the corresponding button. The application also allows syncing to be paused without signing out ("Work offline", in the profile menu): while that lasts, nothing is sent or received, although any changes made are recorded on the device itself and will be uploaded when it reconnects.

Sharing a pot (section 3) is an action taken by the user who shares. The processing of the invited person's email address — which the pot's owner types, which is stored on Dexie Cloud/Awarica AB and which the other members can see — happens because of that action and for that single purpose, to allow access to the pot: it is not used for anything else, and the application sends no email to that address. The invited person is, in turn, a user of the application with an account and a session of their own, and can decline the invitation. The user who shares is responsible for the people they invite (section 2).

The other kinds of processing, described in section 7, have different legal bases: Google Tag Manager is based on the user's consent (Article 6.1.a GDPR), given or withdrawn through the cookie banner; Vercel Web Analytics and Vercel Speed Insights are based on the owner's legitimate interest (Article 6.1.f GDPR) in knowing the aggregated, anonymous usage, and the actual performance, of both sites, given that neither service uses cookies or individually identifies the user. The suggestion box in section 10 is likewise based on consent (Article 6.1.a GDPR), given by the user when they submit the form.

5. Retention and deletion of data

Data stays on the user's browser or device for as long as they do not delete it, do not clear the application's browsing data, and do not uninstall the PWA. The user can delete all their data at any time from within the application itself (Settings section) or by clearing the site's data in their browser.

If the user has turned on syncing, signing out on a particular device deletes the data on that device, but does not by itself delete the copy left on the Dexie Cloud server, which exists precisely to keep syncing with the user's other devices and, for a shared pot, with the other people with access. To request full deletion of that copy (for example, when giving up syncing altogether), you can write to jajimenez+homeconomy@gmail.com.

For shared pots, removing someone does not erase what they have already seen: it only takes away their access from then on (section 3). Deleting a shared pot deletes it for everyone with access; only the pot's owner can do it, and only while online. Signing out deletes the local copy of the data on that device, including that of shared pots, but the other members keep the pot. The pot owner's backups store their shared pots as a private snapshot; an invited person's backups do not include other people's pots.

6. Data sharing and international transfers

While syncing is not turned on, the data the user enters in the application (transactions, loans, pots, people, etc.) is not shared with third parties and does not leave the device. If it is turned on (section 3), it is shared with Dexie Cloud/Awarica AB, based in Sweden: the email address, in the clear, to manage sign-in; the financial content, always encrypted and therefore unreadable to the provider; and the metadata listed in section 3. As this is a country within the European Economic Area, the additional safeguards required for transfers outside it do not apply.

If the user shares a pot (section 3), the pot's content is also communicated to the invited people, who decrypt it on their own devices with the pot's key, and the members' email addresses are shared, in the clear, with Dexie Cloud/Awarica AB, like the rest of the metadata in section 3. That communication is decided by the user who shares; the channel used to get the link to someone lies outside the application and the owner of the application.

The other exceptions, described in the next section, are: (a) Google Tag Manager's third-party analytics, which only activates if the user expressly accepts it and which may involve transferring technical usage data to Google's servers, even outside the European Economic Area, under the safeguards Google provides for such cases; and (b) Vercel Web Analytics and Vercel Speed Insights, the analytics and performance services of Vercel Inc., the company that hosts both sites, which process aggregated and anonymous technical usage and performance data (pages visited, page-load speed metrics, IP address processed transiently to calculate unique visitors, without being stored in the clear), likewise under the safeguards Vercel provides for transfers outside the European Economic Area.

If the user chooses to sign in with a Google account instead of the email code (section 3), Google LLC (United States) is also involved, identifying the user on its own pages and returning the verified email address. No financial data is sent to it, and this step only happens if that sign-in method is used.

On top of all the above there is a separate channel, which does not depend on syncing and is only used if the user chooses to write in: the suggestion box described in section 10, whose recipient is GitHub, Inc. (United States).

7. Cookies, Google Tag Manager and analytics

The application — and only the application, not the public site — uses a service worker (PWA technology) for strictly technical purposes, to enable offline operation and improve performance, without collecting personal or browsing data. This requires no consent and does not depend on the cookie decision described below.

Both sites use Vercel Web Analytics and Vercel Speed Insights, the hosting provider's (Vercel Inc.) own analytics and performance-measurement services, to learn about their aggregated, anonymous usage (most-visited pages, an approximate number of visitors) and their actual performance (load times, Core Web Vitals). Neither one uses cookies or any other persistent identifier, nor allows the user to be individually identified, so both are active from the very first visit and do not depend on the cookie banner. For more information, see Vercel's privacy policy.

Additionally, both sites use Google Tag Manager (GTM), a Google tool that allows measurement and analytics services (for example, Google Analytics) to be configured without having to change the code with every update. GTM and the tools configured through it may use cookies and collect usage data (pages visited, interactions, technical device and browser information) that is sent to Google.

GTM does not load until the user gives express consent in the cookie banner shown on entering either site. If the user declines consent, no Google script loads and no analytics cookie is created. The user can change their decision at any time from "Cookie preferences", in the footer of both sites: withdrawing consent already given deletes any analytics cookies present in the browser and reloads the page to stop measurement immediately, without waiting for the next visit. For more information about the processing Google carries out, see its privacy policy.

To remember that decision, the owner installs its own cookie (home-economy-consent), which stores only whether the user accepted or declined. It contains no identifier, no personal data, and no usage information: just one of those two words. It is a technical, strictly necessary cookie — without it there would be no way to remember a refusal, and the banner would appear again on every visit — so it requires no prior consent. It expires after a year, and the user can delete it at any time from their browser: doing so is equivalent to not having decided yet, and the banner will be shown again.

That cookie is installed for the domain homeconomy.app and its subdomains, so that the decision made on the public site (www.homeconomy.app) also applies to the application (app.homeconomy.app) and vice versa. The reason is not to ask the same person the same question twice.

8. User rights

Since the data lives mainly on the user's device, they exercise their rights of access, rectification, erasure, portability, restriction and objection directly and at all times: they can view, change, export or delete their data from within the application itself, with no need to ask the owner. If they have turned on syncing, exercising these rights over the copy left on the server (beyond signing out on their own devices) may require contacting the owner, as described in section 5. For any query relating to this policy, you can write to jajimenez+homeconomy@gmail.com.

9. Security

The security of the data depends on the user's device and browser. It is recommended to keep the operating system and browser up to date, protect access to the device and, if backups are exported, keep them somewhere safe (or encrypt them, if that option is turned on within the backup itself).

If syncing is also turned on (section 3), the end-to-end encryption the application offers is mandatory, not a recommendation: syncing is not possible without it, so the financial content is never readable by Dexie Cloud/Awarica AB or by the owner as administrator of the project.

The encryption password is never sent to any server and the owner does not know it, but it is kept on the device itself in two cases, so it does not have to be typed in on every startup: the key used to encrypt the data is kept in a local table that is never synced, and the password itself is stored in the browser's local storage only if the user checks "Trust this device" when unlocking (the box can be left unchecked, and on signing out the option to forget it is offered). This is the accepted trade-off for not asking for the password all the time: what the encryption protects is the server and the data in transit, not someone with physical access to an already-unlocked device — hence the recommendation to protect it in the previous paragraph.

If the user loses the password along with the recovery code shown to them when encryption is turned on, their synced data becomes unrecoverable (though it remains safe in any backup they have kept).

10. Suggestion box

The application includes, in the Settings section, an optional form for sending suggestions to the owner. It is the only point in the entire application where the owner receives anything written by the user, and it only works through the user's explicit action: nothing is sent unless the form is filled in and the send button is pressed.

Only the text the user writes is sent; optionally, an email address if they want a reply; and, if they leave the corresponding checkbox on, two technical details shown to them, word for word, on screen before sending: an approximate description of their browser and operating system (for example, "Chrome 141 · Android") and the section of the application they are writing from. No financial data is sent — no transactions, balances, loans, pots or people — unless the user themself writes it into the text of the suggestion, which the form expressly advises against.

The suggestion is published as an issue in a private code repository hosted by GitHub, Inc. (United States), which only the owner can access. That transfer relies on the safeguards GitHub provides for transfers outside the European Economic Area. The IP address it is sent from is used transiently and not retained, for the sole purpose of preventing automated bulk submissions, and is not included in the issue.

The legal basis is the user's consent, given through the very act of submitting the suggestion, and its sole purpose is to improve the application and, where applicable, reply to anyone who has provided an email address. The data is kept for as long as the issue continues to exist; the user can request its deletion by writing to jajimenez+homeconomy@gmail.com.

11. Changes to this policy

This privacy policy may be updated to reflect changes to either site or to applicable law. Any change will be published on this same page.

12. Contact

For any question about this privacy policy, you can write to jajimenez+homeconomy@gmail.com.