pairkan.com▮

problem.
2 人で家計を共有していると「誰がいくら立て替えたか」「いつ精算するか」の小さな摩擦が日々積み上がる。家賃 (25 日締め) / クレカ (10 日締め) / 現金月末 など、締め日と引落タイミングが揃わない支出を 1 つのプールで精算しようとすると、Excel でも一般的な家計簿アプリでも破綻する。自分とパートナーの体験を改善するために、複数の締め日を 1 つのアプリで並行運用できる精算ツールが必要だと判断した。

design.
ドメインを 4 つの一級概念に整理した — Group / Bucket / Cycle / Invoice。Bucket (お支払いまとめ) が締め日とサイクル長を持ち、サイクル毎に 1 つの Invoice を確定する。Invoice は OPEN → PAID → CLOSED の 3 状態で、PAID 以降は明細を凍結 (差し戻し以外で書き換え不可)、確定後の請求書が揺れないことを保証。固定費は半自動化 — テンプレート化された項目を締め時に候補表示し、変動分のみ確認入力する。Postgres の Row Level Security で「グループの 2 人だけが該当行に触れる」制約を DB レイヤに押し込み、アプリ層は薄く保った。

build.
スタックは意図的にミニマル — Next.js 16 (App Router, RSC) / Supabase (Postgres + Auth + RLS) / shadcn/ui + Tailwind v4。ホスティングは Cloudflare Workers (@opennextjs/cloudflare) で常時稼働の無料枠に乗せ、Vercel は DNS 切替で戻せる予備に残置。テストは Vitest を fast / UI レーンに分割、E2E は Playwright (Chromium)。スキーマは supabase/schemas/ を Source of Truth とした schema-first ワークフロー (supabase db diff で migration 自動生成)。Server Components 優先・Client Components はリーフのみという方針で hydration コストを削り、設計→実装→デプロイのループを 1 人分の認知負荷で回せる粒度に保っている。