I hate money: a shared budget web app that has deliberately stopped adding features

What it does, and what it deliberately does not do

I hate money is a web application made to ease shared budget management. It keeps track of who bought what, when and for whom, and helps to settle the bills. The interesting part of the project is the second half of that sentence, because the maintainers have written down where the project is going. It was started in 2011, and they believe it has reached a certain level of maturity, with the overall energy of contributors not as high as it used to be. They also note that there are now several self-hosted alternatives. The conclusion they draw is that the project is still relevant but should gear towards some kind of maintenance mode. So the feature list is not going to grow much, and that is the design decision a user is buying into rather than a sign of neglect. The project is a Flask application on Python, with the primary language recorded as Python and the topics as budget-manager, flask and python.

Simplicity and stability, stated as the two priorities

The maintenance mode section names the priorities. Simplicity is now the main goal, and it has always been a compass for the project, and the resulting software is appreciated by both users and server administrators. The word encompasses both technical aspects, very few javascript code, manageable dependencies and small code size, and user-visible aspects, a straightforward interface, no need to create accounts for the people you invite, and the same web interface on mobile. Stability is prioritised over adding major new features, and the reason given is blunt, that the maintainers found themselves complexifying the codebase and the interface while accepting some contributions. The goal now is a minimal set of features that do most of the job, which they believe will lower the maintenance burden. User interface and user experience improvements are always welcome. New features can still be proposed, but the deciding factors are simplicity of the interface and simplicity of the technical implementation.

The licence, which is beerware and worth reading literally

The code is distributed under a BSD beerware derivative, and the README spells out what that means in one sentence: if you meet the people in person and you want to pay them a craft beer, you are highly encouraged to do so. It is a joke, but a legally meaningful one, because the BSD license text is the grant and the beer is the exhortation. The repository is listed with a custom licence that GitHub cannot classify, which is consistent with a modified BSD. The practical consequence for an organisation is that the licence is permissive and the ask is a beer, which makes it one of the easier licences to adopt and the harder to justify in a procurement process, so a company deploying it internally should decide how to handle that rather than discovering it later. The copyright and the project lead are recorded in the packaging metadata as Alexis Métaireau and contributors.

Requirements, backends and the supported environments

The requirements are Python version 3.11 to 3.13, and the backends are SQLite, PostgreSQL, MariaDB at version 10.3.2 or above, and Memory. SQLite is the default and the container example uses it, with the database file in a volume. The support policy is stated in terms of the distribution rather than the version, with the aim of supporting the software environment of the current Linux Debian stable and the previous one, old-stable, and Docker installation offered for broader support. The packaging metadata agrees on the Python range with requires-python of 3.11 or later and classifiers for 3.11, 3.12 and 3.13, and the project version is 7.2.2.dev0 with the released tags 7.1.1 from May 2026, 7.2.0 from August 2026 and 7.2.1 on 2026-08-07.

The Docker image, and the configuration that matters

The Dockerfile is a single stage on python:3.11-alpine that installs build dependencies, then the runtime packages, then the project with the database extra, and creates a user abc with uid 1000 so the container does not run as root. The entrypoint is a script in conf/, and the database directory is a volume with port 8000 exposed. The example docker-compose.yml in the repository is explicit that it is an example and that the configuration variables should be changed, and it shows the whole configuration surface as environment variables, including DEBUG, ACTIVATE_DEMO_PROJECT, ACTIVATE_ADMIN_DASHBOARD, ADMIN_PASSWORD, ALLOW_PUBLIC_PROJECT_CREATION, the mail settings, SECRET_KEY, SESSION_COOKIE_SECURE, the SQLALCHEMY_DATABASE_URI, APPLICATION_ROOT, ENABLE_CAPTCHA and LEGAL_LINK. Two of those deserve attention. The compose file explains that an admin password hash can be generated with a container command, and that every dollar character in the result must be doubled. And SECRET_KEY is set to tralala in the example, which is fine for a demo and fatal in production.

services:
  ihatemoney:
    image: ihatemoney/ihatemoney:latest
    environment:
      - SECRET_KEY=tralala
      - SESSION_COOKIE_SECURE=True
      - SQLALCHEMY_DATABASE_URI=sqlite:////database/ihatemoney.db
    volumes:
      - /path/to/local/dir/for/sqlite/db:/database
    ports:
      - "8000:8000"

The dependency list, and what it reveals about the design

The pyproject.toml dependency list is long for an application with a simplicity goal, and reading it tells you what the app is made of. Flask 3.1 with Flask-SQLAlchemy and SQLAlchemy 2.0, Flask-Migrate for schema migrations, Flask-Babel for translation, Flask-WTF with WTForms for forms, Flask-Talisman for security headers, Flask-Limiter for rate limiting, Flask-Cors, Flask-Mail for outgoing mail, Flask-RESTful for the API, and Jinja2 for templates. Then the specific libraries for the domain, with the debts package for the settlement maths, the cachetools for caching, email_validator for the address checks, qrcode for generating the project QR codes, python-dateutil, and requests, which the comment says is used only by the currency convertor. The inline comments show the maintainers tracking upstream activity, since several entries carry a last update date and Flask-Migrate is noted as not following semantic versioning. The optional database extra adds psycopg2-binary and PyMySQL for the non-SQLite backends.

How the project builds, tests and releases

The Makefile is built on uv rather than pip, with a virtualenv target, a serve target that runs the dev server with FLASK_DEBUG and FLASK_APP set to ihatemoney.wsgi, and a test target that runs pytest with the dev and database extras. The lint target is two tools, ruff check and vermin, and vermin is run with a target of 3.8 to 3.8 minus, which is a clever trick since the project supports 3.11 to 3.13 and vermin is being used to find syntax that would not run on the oldest supported interpreter. The format target is ruff format. The release target runs a fullrelease command through uv. There are also asset compression targets using ImageMagick mogrify to produce webp showcase images and ZopfliPNG to recompress the PNGs, and the compress-assets target depends on compress-showcase. The build system is Hatchling, with the version pinned to hatchling 1.21.1 and a comment explaining the downgrade was to avoid an InvalidDistribution crash on the release make target.

Community, translation and where the hosted version fits

The project has a documentation site, a hosted version at ihatemoney.org, a cloud provider installation page, and a mailing list for update notifications. There is a Liberapay donation link, and the README says all funds will be used to maintain the hosted version, which is a useful thing to know when deciding whether to self-host or to use the hosted instance. Translation runs through Weblate, with a status widget per language, and the site is documented in English while the code carries the locale machinery through Flask-Babel and the BABEL_DEFAULT_TIMEZONE setting in the container. The last push to the repository was on 2026-08-07, the repository is not archived, and the primary language is Python. The recent activity and the stated maintenance mode point the same way, which is that this is software that works, that gets careful fixes, and that is not going to surprise you.

Editorial conclusion

I hate money suits a group of friends, a flat share or a small team that wants a simple web app for splitting costs, self-hosted or on the hosted version, without accounts for the people you invite. It is the wrong choice if you need a full accounting or expense product, because the project has deliberately stopped adding major features, and a poor fit if you need a maintained community, since the maintainers say contributor energy is not what it was. Before adopting it, read the current direction section, because it tells you the project will accept a feature only if it fits the simplicity goal, and if you self-host, plan the SECRET_KEY and SESSION_COOKIE_SECURE settings first, since the example configuration ships with obvious defaults.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. spiral-project/ihatemoney on GitHub