There's a version of palStack that would have been easier to build. One app, one login, one database, and a sidebar with Money, Pantry, House and Friends in it. You sign up once and everything is there. It's the obvious shape for a family of tools, and it's what most people assume we built.
We never wanted that version. From the start, we wanted the pals to be separate, because each one does its own thing. January 28, 2026 is when we finally set everything up that way: every pal got its own repositories, and from then on each one has its own code, its own database and its own login. finPal and pantryPal don't share a line of code. If you use both, you have two accounts. That sounds like a worse product until you look at what each pal actually does.
Four apps that have nothing in common but a name
finPal is about money. It's careful, a little serious, full of numbers that have to be exactly right, and it's often used by two people who share a household budget. pantryPal is about groceries. It's fast and casual, you use it standing in a kitchen with a bag in one hand, and most of its value is in a camera that reads receipts. propertyPal is about owning a home, which turns out to mean documents, warranties, maintenance schedules, and for some people tenants and tax forms. clubPal is about friends, and whose turn it is to pick the restaurant this month.
When I lined them up honestly, the thing they shared was a philosophy, not a product. Private by default, self-hostable, no ads, no selling your data. That's a promise we can keep across every app. A shared login screen isn't the thing that makes them a family.
The reasoning has always come down to two things. Each pal does something genuinely different, and keeping them separate lets us play with how each one looks and how each one serves the people using it.
Each one gets to look like its job
That second reason turned out to matter more than I expected.
Because nothing is shared, every pal has been redesigned on its own terms. propertyPal went dark and structured, a deep navy we call Deep Space, with a sidebar organized around the rooms of your house and a marketplace for add-ons. pantryPal's mobile app went the other way, light and translucent, built around Apple's newer glass look, because it lives on a phone in a kitchen. finPal's redesign is warm and quiet on purpose. The direction we picked is called Kitchen Table, and its whole thesis is that a household budget is a home, not a trading desk.
Three redesigns in one year, three completely different moods, and none of them had to be negotiated with the others. In a single app, those would have been one design system arguing with itself, and the result would have been a compromise that fit none of them.
The same freedom goes below the surface. The pals don't even share a tech stack. finPal is Flask with a React front end. pantryPal and clubPal are sets of small FastAPI services. propertyPal is Flask with its own React app. Each was built the way its problem wanted when we built it, and nobody has to migrate the others when one changes.
Each one gets to serve its people differently
Separate products also means separate plans. Each pal has its own free tier and its own idea of what's worth paying for, because what a landlord needs from propertyPal has nothing to do with what a dinner club needs from clubPal. Each has an open-source core edition that you can run yourself, forever, and a hosted edition we run for you. Each has its own page, its own address and its own story.
It also means a bug in one can't take down the others. That isolation is a nice side effect, but I want to be honest that it wasn't the reason. The reason was the product, not the uptime.
What it cost
Splitting things apart isn't free, and I'd be writing a brochure if I skipped this part.
The biggest cost is that we build some things more than once. Login is the clearest example. Four pals means four sign-in systems, four password resets, four places for two-factor authentication to go wrong. Every one of those had to be built, tested and secured separately.
The quieter cost is that a lesson learned in one pal doesn't travel on its own. In September we found that pantryPal could crash on a malformed answer from a language model and fixed it. The same day we found the exact same unprotected code in carPal, petPal and clubPal, because each had grown its own copy. Nothing shared meant nothing to fix once.
Where sharing came back
We didn't end up with zero shared pieces. We ended up sharing in a different way. Instead of shared code that every app imports, we built shared services that every app talks to.
There are two of them. adminPal is our back office, one place where we manage users and plans across every pal. It talks to each pal over the network with a request signed by a secret that belongs to that pal alone, so no pal has to trust another. And there's the AI service, where every language model call in palStack goes, which I'll write about in detail soon.
The difference sounds technical but it matters. When code is shared, every app has to move together. When a service is shared, each app just needs to know its address. finPal can change everything about itself and never touch adminPal, as long as it keeps answering the same questions.
Would I do it again
Yes, and more confidently now than in January. The duplicated work is real, but it's the kind of cost you can see and plan for. The alternative, one app trying to be a finance tool, a pantry, a home manager and a social calendar at once, has a cost you only see later, when every design decision is a fight and every release is all four products at once.
palStack is a family, not a single app. The family resemblance is in what we promise you, not in a shared login screen.