The first time I tried to self-host a personal finance app, I spent two evenings getting it to run and a third evening understanding why I wasn't going to use it. The thing worked, technically. It also required a Redis instance, a separate background worker, an nginx reverse proxy configured just so, and about twenty environment variables that the docs described as "straightforward." I didn't need a finance app that badly. Nobody does.
That was 2023. My partner and I were trying to do something simple: track our shared expenses and stick to a budget. We looked at the cloud options too. The problem wasn't cost. It was that every app we tried wanted our financial data on their servers, and neither of us was comfortable with that. We're technical enough to know what that actually means, what gets collected, what gets sold, what you're agreeing to when you click accept. So we went looking for something we could run ourselves, on our own hardware.
What we found was: either too simple to be useful, or too complex to actually deploy. Nothing in between. So I built it. The first thing I made was called Dollar Dollar Bill Y'all. Yes, really. It's a self-hosted money management and expense splitting app: budget tracking, multi-currency support, shared expense settlement, bank sync via SimpleFin. Flask on the backend, Docker deployment, dead simple to run. I had it up on my home server in an afternoon. We used it, it worked, and at some point I put it on GitHub because I figured someone else must have the same problem.
329 GitHub stars later, that assumption seems to have been correct.
It's since been rebuilt and renamed finPal, and it's part of a larger ecosystem now. But the original instinct was right: people want tools that work, that they can run themselves, and that don't treat them like a data source. The market for that is not small.
That instinct kept showing up in places that had nothing to do with money, though, which is how I ended up realizing this wasn't a finance app problem. It was just how I notice problems. We have a basement pantry and we were consistently wasting food because we had no idea what was already down there. We'd buy something, forget we had it, buy it again. Simple problem, obvious solution, and yet every "pantry management" app I found was either a subscription product with cloud storage or a half-finished open-source project that hadn't been touched in two years.
So I built pantryPal. Track what's in your pantry, scan receipts, see what you have, reduce waste. Self-hosted, your data stays home.
Then we bought our first home, and the learning curve of being a homeowner was steeper than I expected. Warranties to track. Maintenance schedules I didn't know existed. A water heater that apparently needs to be flushed annually (I did not know this). Every time I went looking for a tool to manage this stuff, I ran into the same choice: overpowered property management software built for landlords, or a notes app. So I built propertyPal. Track maintenance, set recurring reminders, keep warranties in one place.
Three apps. Three times the same experience: real need, no good option, build it yourself. At some point you stop calling that a hobby and start calling it something else.
That's the actual shape of how palStack came to exist, one household annoyance at a time, not a plan drawn up on a whiteboard. What it's become, in practice, is an open-source ecosystem of privacy-first, self-hostable tools for everyday life. Each app solves one specific thing really well. They're all designed to run on your own infrastructure with a single Docker command, not a weekend of configuration. The data stays with you. There's no subscription, no analytics pipeline, no ad targeting model running in the background.
services:
pantrypal:
image: ghcr.io/palstack-io/pantrypal:latest
ports:
- "8080:8080"
volumes:
- ./data:/data
restart: unless-stopped
That's genuinely the whole thing. docker compose up -d and it's running.
No Redis instance you didn't ask for, no separate worker process, no nginx config to get
just right. If you've ever self-hosted something that fought you the whole way, that's the
exact experience we built every one of these apps to not be.
The name comes from a line we settled on early: that's what pals do, they show up and help with the everyday stuff. Not the grand things. The unglamorous, recurring, slightly annoying things that pile up when you're an adult with a home and a budget and a pantry and a thousand other things to track. We wanted to build software that felt like that. Helpful without being intrusive. Useful without being complicated.
There's a team now: Rachel handles marketing, branding, and sustainability. Elle leads UI/UX. Chris runs our DevOps and systems. Chaitanya advises on security. We're small and we intend to stay that way for a while. The products we want to build don't require scale to be good. They require care.
There's one decision underneath all of it worth explaining on its own, since we get asked about it a lot: everything we build is open source. The honest answer is that it felt like the only coherent choice given what we're building. If the whole point is that you shouldn't have to trust us with your data, you should be able to read the code and confirm that. Open source isn't just a distribution strategy here. It's the proof.
It also means that when someone needs finPal to work in euros instead of dollars, they can just make that happen. When someone runs it on Unraid, they can build a template and share it. The community has done more to shape these products than we could have done on our own, and we're genuinely grateful for that.
Where things actually stand changes every few months, so here's the honest snapshot rather than a roadmap I'd have to keep rewriting:
| App | What it solves | Status |
|---|---|---|
| finPal | multi-currency budgeting & bill splitting | web live, mobile in progress |
| pantryPal | pantry inventory & expiry tracking | deployable |
| propertyPal | home maintenance & warranty tracking | active development |
| pointsPal | credit card points tracking | early build |
| clubPal | rotating group activities (dinner clubs, book clubs) | early build |
I'll write about all of it here. The decisions we're making and why, the things we got wrong, what it actually looks like to build something in public while also holding down a full-time job in data engineering. It's not glamorous. But it's real, and I think the honest version is more useful to anyone thinking about doing something similar than the polished retrospective version would be.
If you want to see what we're building, the code is all at github.com/palStack-io. If you want to follow along here, I don't have a fixed schedule. New posts go up whenever there's something real to share.