Piggy: a family finance tracker with an Angular front end and a Flutter app

What Piggy is, and what it is not

Piggy is a family finance management app, and the README is clear that it is a personal project. It is a side project of Abhith Rajan, a full-stack developer focused on different stacks, and the Flutter client in particular is explicitly not his main area.

That framing explains most of what you see in the repository, including the invitation at the end of the technology stack section: if you are a Flutter person, have a look at the code and see how you can improve it. A project maintained by someone whose day job uses other stacks is a different thing from a product with a roadmap and a support commitment, and it is worth naming that difference before anyone builds on it.

The feature surface, though, is real and reasonably complete for its purpose. The screenshot list in the README runs through a main overview screen, account list with collapsed and expanded states, archived accounts, account add and edit forms, an account details view with a search, a recent transactions list with a collapsed variant, add and delete transaction flows, a calculator on the add transaction form, a user profile, push notifications and local reminders, transaction details with comments, category list, category detail and edit, category add, a drawer navigation, a reports screen, a categorywise accounts report with a date selector, a categorywise recent months report, a settings screen, a default currency setting and an about page.

The presence of comments on transactions, of local reminders and of a default currency setting is what makes it a family app rather than a single-user tracker. Shared accounts with multiple people, each of whom can annotate a transaction, is the actual use case.

The primary language is Dart, the licence is MIT, the default branch is main, and the homepage is piggyvault.abhith.net.

The two front ends and the decision to retire the web one

The technology stack is split, and the split has a story behind it.

The web side is ASP.NET Core, Angular and MSSQL. The mobile side is Flutter. The README then explains what happened to the web front end: Piggy previously used to have a functional website with all the features, but the evolution of its mobile app made it redundant, so the maintainer stopped working on it, and now the website hosts the APIs only.

That is a genuine architectural decision rather than an unfinished state. When one client covers the whole feature set, maintaining a second one in a different framework is duplicated work with no payoff. The Angular code is still in the repository, but it is no longer the product.

The reason the API stack is what it is appears in the credits. The backend credits aspnetboilerplate, which is a well known ASP.NET Core application framework built around a module and tenant system, and that explains the tenant and user management guide in the docs.

The two guides the README points at are the Initial Setup Guide in docs/SETUP_GUIDE.md and a Tenant and User management document in docs/PORTAL.md. The second one is a tell: multi-tenancy is not an afterthought here, it is a first-class part of the model, and the portal documentation is where you would find out how a user is created, scoped and given access.

The repository layout follows the same split, with a src/ directory holding the code and a separate docs/ directory for the guides, and the images/ directory holding the animated and static screenshots that make up the README's feature tour.

The Android workflow is described in the screenshots too, with animated GIFs for the main screen, the add transaction form, the delete flow, the add account flow and the recent list, alongside static captures of the older screens.

Continuous integration across three stacks, and the quality tooling

The badge row at the top of the README is unusual enough to be worth reading carefully, because it shows a repository that runs three separate build pipelines.

There is a Flutter workflow, a .NET workflow and an Angular CI workflow, each with its own badge and its own continuous integration run. Three pipelines for three toolchains means a change to the Flutter client, the API or the Angular code is verified independently, and it also means the CI setup is three times the surface to maintain.

Alongside those, the FOSSA status badge tracks the licence and dependency analysis, and a long row of SonarCloud badges covers the static analysis picture. There is a quality gate status for the overall alert state, then separate measures for bugs, code smells, duplicated lines density, lines of code, maintainability rating, reliability rating, security rating and technical debt, and a vulnerabilities count.

The duplicated lines density metric is the one that hints at the codebase's shape. A finance app with a Flutter client, an Angular portal and a .NET API has three places where a data model is described, and the duplication metric is the standard way a static analysis tool tells you whether those descriptions have drifted apart.

The static analysis configuration lives in a .sonarcloud.properties file at the repository root, and the .github/ directory holds the workflow definitions.

There is also a Discord badge, which points at where the actual conversation about the project happens. For a project of this size that is a reasonable arrangement, and it is also a reminder that the answers to most setup questions will be in a chat rather than in the repository.

The topic tags on the repository are broader than the actual code: alongside finance, flutter, mobile-app, money-manager and moneytracker, they include abp, csharp, dotnet-core and dart2. The aspnetboilerplate dependency in particular explains the ABP and C# tags, since the API layer inherits that framework's structure even though the repository's primary language is Dart.

Getting the app and the test account

There is no build-from-source walkthrough in the README itself, so the honest answer is where the project points you: the Initial Setup Guide at docs/SETUP_GUIDE.md.

For the mobile app, the Try it out section is much simpler. You grab the APK from the latest release on GitHub.

The releases page also carries the version history, and the recent tags are 0.35.1 from 2024-09-22, 0.35.0 from 2023-08-05 and 0.34.2 from 2023-03-07. That sequence is worth reading carefully, because it separates two things: the repository is being worked on, with the last push on 2026-10-17, but the published APK is from September 2024. If you install the APK from the releases page, you are running code from 2024; if you build from the current source, you are running something the maintainer has not shipped.

The README also provides test credentials for the default family account, with the username admin and the password 123qwe. That is what you would use to sign into a fresh install and look around before setting up anything.

For the API and portal, the setup guide is the path, and it will be the one that tells you about the MSSQL database, the ASP.NET Core service and how the Angular portal is wired to the API. The Tenant and User management guide then covers the part that a self-hosted install has to get right, which is not the money tracking but the accounts and the people.

The Development Status section points at the repository's projects tab for what is planned and what is going on now, and says high-level planned items can be viewed under the organization's projects. That is a more reliable place to judge the roadmap than the issue tracker.

What the project says about using it yourself

There is a paragraph in the README about adoption that is more candid than most, and it is the one to quote when someone asks whether this is usable.

Piggy works fine for Abhith and his family. If you are interested, we may be able to make it work for you too. Let's discuss further in the discussions.

Read precisely, that is a statement about the state of the software. It works for one specific family, in one specific configuration, and for anyone else there is an open question of whether it can be made to work. That is not the same as a project with a community that has already solved your configuration, and the distinction matters if you are about to depend on it.

There is also a technical reason behind the caveat, and it is the multi-tenancy. The API is built on aspnetboilerplate, which gives you tenants and users and roles, but a family finance app with tenant support has to decide what a tenant is. In a family context, a tenant is probably a family, and the members of that family are users inside it. For a self-hoster who wants one instance for one household, that is more machinery than needed, and configuring it is the work the PORTAL guide exists for.

For a developer, that cuts both ways. The tenant model is a feature if you want to host several families in one deployment, which is exactly the shape a hosted service would take. It is overhead if you want a private instance for your own household.

The MIT licence means none of this is a legal obstacle. You can read the code, run it, change it and redistribute it, and the FOSSA badge suggests licence compliance is tracked on the dependencies as well.

Where Piggy is the wrong choice

There are three limits, and the first is about the web application rather than the data.

The first is that the web front end is gone as a product. If your requirement is a browser-based finance tool for a family that will not install an Android app, Piggy does not offer one any more, because the website now hosts the APIs only. The Angular code is still there and the CI still runs, but the maintainer stopped working on it, so a web client is a project you would be taking on rather than adopting.

The second is the Flutter code quality, and the README says so itself. The maintainer is a full-stack developer focused on different stacks and Flutter is not one of them yet, hence tons of improvements can be done to the Flutter project. That is an invitation to contribute, and it is also a statement that the mobile client is the weaker half of the codebase. Anyone adopting this to do serious work on the mobile app should budget for fixing what they find rather than assuming a polished client.

The third is the version gap. The last push was on 2026-10-17 and the repository is not archived, so work is happening. The last tagged release is 0.35.1 from 2024-09-22, and the release before that is from 2023. A version that has not been cut for two years while the source moves is a project where the deployed artefact and the source can diverge in ways you will not see from a tag. The dependency set of a Flutter app from September 2024 is also two years behind what a current build would pull.

The honest alternative depends on what you actually need. If you want a shared family finance tracker that works today with no hosting and no assembly, a hosted personal finance service does the job with none of this setup cost. If you want to self-host and to own the data, a more general personal finance server gives you a maintained project with a container image and a documented upgrade path, at the cost of not having the specific feature set Piggy has chosen, which is the per-family tenancy and the Flutter client. If you want to build on the code rather than run it, the ASP.NET Core and Angular stack is a common and well-supported combination, and the MIT licence means the backend and the Angular portal are a reasonable starting point for a product of your own.

What Piggy offers that those alternatives do not is a complete family finance application with the tenancy already modelled and a mobile client built, that you can point at your own database and adjust. If you are prepared to be the maintainer of your own deployment, that is a reasonable deal.

Editorial conclusion

Adopt Piggy if you want a self-hosted multi-user family finance tracker with a Flutter client and a tenant model already built, since the API and portal handle users, accounts, transactions and categories out of the box. Do not adopt it if you want a finished web product, because the README says the website hosted all features once but the mobile app made it redundant and it now hosts the APIs only. Before you start, read docs/SETUP_GUIDE.md, and note the last push was on 2026-10-17 with the last release 0.35.1 from 2024-09-22.

Frequently asked questions

Official sources

1. License: MIT
2. piggyvault/piggyvault on GitHub
3. Project website
4. README
5. Releases