pairkan.com▮

problem.
Couples and families sharing a household accumulate constant low-grade friction — who fronted what, and when to settle up. Expenses with different closing dates (rent on the 25th, credit card on the 10th, cash month-end) break when squeezed into a single pool by spreadsheets or generic budgeting apps. I built it because my partner and I needed a settlement tool that handles multiple closing cycles natively in one app.

design.
Modeled the domain around four first-class concepts — Group / Bucket / Cycle / Invoice. A Bucket carries the closing day and cycle length; each cycle finalizes into one Invoice with the OPEN → PAID → CLOSED state machine. After PAID, line items freeze (no edits except an explicit revert), so the issued bill doesn't shift under the receiver's feet. Recurring costs are semi-automated: templated items appear as candidates at close time, with only the variable portion entered by hand. Postgres Row Level Security pushes the "only the two members of this group can touch these rows" rule into the database layer, keeping the app layer thin.

build.
Deliberately minimal stack — Next.js 16 (App Router, RSC), Supabase (Postgres + Auth + RLS), shadcn/ui + Tailwind v4. Cloudflare Workers via @opennextjs/cloudflare for always-on edge execution on the free tier; Vercel kept as a DNS-flip backup. Tests split into Vitest fast / UI lanes plus Playwright (Chromium) E2E. Schema-first workflow with supabase/schemas/ as the source of truth and supabase db diff generating migrations. Server Components by default, Client Components only at leaves, to keep hydration cost low — and the design → implement → deploy loop tractable for one person.