I designed, built, and launched Pitch In, a multi-tenant SaaS where a household keeps its money, its bills, and its chores in one place, and everyone who lives there gets their own sign-in. It started as my own family’s budget app and is now live, open to anyone, with real households in it.
Household money apps like YNAB, Monarch, and Copilot are built for the one person who does the books. Kids’ allowance apps like Greenlight and GoHenry are built around a debit card and treat the child as the whole account. Nobody serves both halves of the same house.
That gap is widest in a household with teenagers. They are old enough to do chores that matter and hold money of their own, but not old enough to be shown the mortgage. The product had to make a shared household ledger safe to hand to a 15-year-old, and it had to go from one family to many without breaking the app my own family relies on every day.
Prove it at home, then generalize. I kept two codebases on purpose. The family app stays single-household and fast-moving, and features get proven there with real bills and real chores before they're ported into Pitch In. A written working agreement between the two repos keeps ideas flowing one way, so what ships in the product has already been used for real.
Per-member visibility, enforced in the database. A parent sees every balance and every bill. A teenager might see their chores and nothing else, or spending without balances, or one shared account. A withheld account isn’t blurred or shown as zero. It simply isn’t there, and it drops out of their totals. That rule is enforced in the data layer, so a screen that forgets to ask “who is looking?” doesn’t compile.
A real SaaS foundation. Each household's data is isolated with Postgres row-level security, under a restricted database role that can’t bypass it. On top of that sit email and Google sign-in, two-factor with trusted devices, invitations, roles, and multi-household membership (for separated co-parents and adult kids helping a parent). There's also an operator console for access requests and announcements, and versioned legal consent recorded from day one.
The other side of the product. A SaaS also needs a console for the person running it, and Pitch In’s gets the same design care as the app: sign-ups and the funnel to real use, plans and revenue against running costs, access requests to grant, feedback to answer, and an activity log of sign-ins and email delivery. It draws one line on purpose: who each account is, never what’s in it. Row-level security means the console can’t read a household’s chores or money even if a screen asked. The console screens above use made-up sample households.
Designed like a product, not a project. Pitch In has its own brand book, a logo generated from parameters so it never drifts between files, and a type system with a monospace for the amounts in lists. The landing page puts a parent’s view next to a teenager’s because that comparison is the product. A no-account demo household lets anyone try it, and the app installs to a phone with push notifications.
Pitch In is live at pitchin.house with open sign-up and real households using it. Everything a household types in is free, and the paid Connected plan, $10 a month per household, fills itself in from the household’s bank. Brand, product design, front end, back end, infrastructure, billing, and legal were all delivered end to end by one person.
It runs on a Next.js and TypeScript monorepo on Vercel, with Postgres on Neon and Better Auth, and it has no analytics, no tracking, and no ads. Next up is the bridge between chores and money: chores that earn an allowance. It's a ledger, not a bank, so the product records what was earned and never holds anyone’s money. The near-term goal is ten families who would be annoyed if it disappeared.
Have a house full of people who all pitch in? Create your household, or read the story behind it in From Our Family’s Budget App to a Product.