BeeCount: a local-first Flutter bookkeeping app with five sync backends

The problem BeeCount solves, and the person it is built for

Most expense trackers keep your ledger on someone else's server. You get a login, a sync that works, and no way to audit what happens to the rows. BeeCount takes the opposite position. The README frames the comparison directly: data stored with a third party cannot be audited, while BeeCount is offline-first with a self-hosted cloud option, so the developer has no access to your data. The stated goal is data sovereignty, with five sync schemes to choose from.

The audience follows from that. This is for someone who already runs a NAS, a VPS, or a Docker host and is comfortable pointing an app at their own storage. It is also for people who only want one device: the app is offline-first, so a local SQLite database via Drift is the baseline, and sync is optional. Platform support is Android 5.0+, iOS 15.5+, and Web through the self-hosted BeeCount Cloud. HarmonyOS support is marked as discontinued in the README, with the openharmony repository linked as stopped.

The feature set is the ordinary one done thoroughly: multiple ledgers with independent currencies, multiple accounts where transfers update both balances, two-level categories, monthly and per-category budgets with overspend alerts, recurring entries on daily, weekly, monthly or yearly schedules, coloured tags, chart analysis, and CSV plus YAML import and export. Nothing there is novel. What is less common is that AI, OCR and voice capture are described as free rather than paywalled, and that the sync layer is pluggable rather than fixed to one vendor.

How the sync layer and AI capture actually work

The architecture is a Flutter client over a local Drift (SQLite) database, with Riverpod for state management. Sync is a separate concern layered on top, and the README lists five backends with different trade-offs. BeeCount Cloud is the self-hosted option: a Docker image that contains both server and web client, WebSocket push for multi-device updates, multiple user accounts with isolated data, shared ledgers with Owner and Editor roles, and AES-256 encrypted backups fanned out to R2, S3, WebDAV or B2. The README states that a backup can be restored with standard unzip tools if the service is lost, which is the detail that makes the encryption claim checkable rather than decorative. iCloud is the zero-configuration path for iOS-only users. Supabase is aimed at cross-platform users without a NAS. WebDAV targets NAS owners, naming Synology, UGREEN and Nextcloud. S3 covers Cloudflare R2, AWS S3 and MinIO.

AI capture is a separate pipeline with two OCR engines: a local TFLite model and a cloud GLM path. The README says the app recognises screenshots from Alipay, WeChat and UnionPay, and that the conversational assistant is built on Zhipu GLM-4. Voice entry takes spoken phrasing such as a grocery purchase and converts it to a transaction. On Android, an accessibility service watches for screenshots; on iOS, a Shortcuts double-tap on the back of the phone triggers capture. The MCP integration is the newest piece: paired with BeeCount Cloud, an LLM can manage ledgers directly. Note what that implies. The AI features send data to a GLM endpoint, so the privacy-first framing applies to storage and sync, not to AI capture. If that matters to you, the local TFLite OCR path is the one to check.

Installing BeeCount and recording a first transaction

There are three install routes, and which one you take depends on whether you want to build the app or just use it. For end users, the README links the App Store listing, Google Play, and an APK on the releases page, plus a TestFlight link. For the Web client, the README points at the separate BeeCount-Cloud repository, which carries the Docker Compose deployment instructions, backup system and PWA details. This repository is the client; the server lives elsewhere.

If you want to build from source, the README gives the Flutter workflow. Flutter 3.27 or newer is required. Dependency installation, code generation and a dev-flavour run look like this:

flutter pub get
dart run build_runner build --delete-conflicting-outputs
flutter run --flavor dev

The build_runner step is not optional: Drift generates database code, and skipping it leaves the project without the generated files it needs. A release APK uses the prod flavour:

flutter build apk --flavor prod --release

Once the app is running, the first useful action is a manual entry, because that works with no sync configured at all. Open the add-transaction screen, enter an amount, pick a category and an account, and save. The README's demo folder contains a 100-record and a 10,000-record dataset, which is a reasonable way to see how the charts and lists behave before you commit real data. After that, pick a sync backend from the table in the README and follow docs/cloud-setup.md, which the README names as the configuration guide for all five options.

Where BeeCount is the wrong tool

The licence is the first thing to resolve. The README badge says Business Source License, the repository contains both LICENSE and LICENSE_EN plus a separate COMMERCIAL_LICENSE.md, and the GitHub API reports the licence as NOASSERTION. That is not a permissive open source licence in the OSI sense, and the repository does not spell out the restrictions in the README itself. If you are evaluating this for anything commercial, the licence files are the first thing to read, and I would treat the "open source" framing in the README as marketing shorthand rather than a licence statement.

The second boundary is operational. BeeCount Cloud is a Docker deployment you own. That means backups, upgrades, TLS, and the WebSocket endpoint are your problem. The README advertises "one-click Docker" and second-level sync, but a self-hosted sync server is a service with an uptime requirement, and nothing in this repository provides one for you. If you want someone else to be responsible when sync breaks, this is the wrong architecture.

The third is AI capture. The cloud OCR and assistant paths route through GLM-4, which the README describes as a cloud model. Anyone choosing BeeCount specifically because they do not want their financial data leaving their control should either stay on the local TFLite OCR engine or turn the AI features off, and the README does not document a per-feature data-flow breakdown for that decision. Finally, HarmonyOS users are out: the README marks that port as discontinued.

BeeCount compared with Supabase-only and plain CSV trackers

The closest thing to a direct alternative inside this same category is a spreadsheet or a CSV-driven tracker, and the difference is structural rather than cosmetic. A CSV workflow has no sync conflict resolution, no account balances that update on transfer, and no recurring entries; BeeCount has all three because it runs a relational SQLite database with a sync layer on top. The cost of that is that your data lives in a Drift schema, and getting it out means the CSV and YAML export the README documents rather than opening a file.

A more interesting comparison is BeeCount against using Supabase directly, which BeeCount itself supports as one of the five backends. Supabase alone gives you a hosted Postgres database and auth, with a free tier the README calls sufficient. BeeCount on Supabase gives you the same backend plus a client that already models ledgers, accounts, categories, budgets and tags, and handles the offline-first merge. The trade-off is that Supabase is a hosted dependency: if the project or your free tier goes away, you are exporting rows. BeeCount Cloud removes that dependency but adds a server for you to run. The README positions BeeCount Cloud as the recommended option for anyone with a NAS, VPS or Docker environment, and that recommendation is consistent with the architecture rather than with the licence.

Maintenance, releases and what upgrading costs you

The repository is not archived, and the last push was on 2026-09-07. Releases are frequent: 3.8.0 on 2026-09-06, 3.7.3 on 2026-08-31, and 3.7.2 on 2026-08-17. That cadence suggests active work, and the version numbers move in small increments rather than jumping, which usually means incremental fixes rather than rewrites.

The upgrade risk sits in two places. First, Flutter and Dart SDK upgrades: the README requires Flutter 3.27+, and any project that pins a minimum SDK will eventually need the build_runner regeneration step again after a dependency bump. Second, the Drift schema. Drift migrations are the part of a Flutter app most likely to break across versions, and the README does not document a migration policy or a rollback path for the local database. Before upgrading a device that holds your real ledger, export to CSV or YAML through the built-in export, which the README lists as a feature, and keep the file. That is the only recovery mechanism the README describes.

On licence implications, I can only point at the files: LICENSE, LICENSE_EN, COMMERCIAL_LICENSE.md and THIRD-PARTY-NOTICES.md are all present at the top level. The README's Business Source License badge and the separate commercial licence file indicate that commercial use has conditions attached. That is a question for your own legal review, not something the README answers.

Editorial conclusion

Adopt BeeCount if you want an auditable personal ledger on your own devices and you are willing to run BeeCount Cloud in Docker for multi-device sync, or to settle for iCloud, Supabase, WebDAV or an S3 bucket. Skip it if you need a hosted service with an uptime commitment, or if you plan to build a commercial product on the code: the repository ships a Business Source License and a separate COMMERCIAL_LICENSE.md, and the GitHub API reports the licence as NOASSERTION, so read LICENSE, LICENSE_EN and COMMERCIAL_LICENSE.md yourself before you depend on it. Verify the Docker Compose path in the separate BeeCount-Cloud repository first, since that is where deployment, backup and PWA details live.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. TNT-Likely/BeeCount on GitHub