4 Months of Building SubBuddy Solo—What I'd Do Differently

January 18, 2026

Hey Indie Hackers,

It's been 4 months since I shared my initial roadmap for SubBuddy. I've shipped family sharing, CSV import, calendar sync, i18n, a full UI overhaul, and more. 109 commits later, I want to share what I learned—especially the stuff I wish I knew at the start.

⏰ What Took Way Longer Than Expected

1. Row-Level Security for Family Sharing

I thought family sharing would take 2 weeks. It took 6.

Supabase RLS is powerful, but I ran into an infinite recursion bug that took days to debug. The issue? My RLS policy was querying a table that had its own RLS policy, which queried another table... you get it.

Lesson: Sketch out your RLS policies on paper before writing SQL. Understand the call chain.

2. Internationalization (i18n)

Adding Spanish support meant touching every page, component, and metadata file. I underestimated how much text lives outside components—error messages, email templates, SEO meta tags, even the 404 page.

I ended up with 3 separate translation files (general, legal, pages) just to keep things organized.

Lesson: If you think you'll ever want i18n, set it up on day one. Retrofitting is painful.

3. The Dashboard Overhaul

I thought "refresh the UI" would be a weekend project. It became a 6-part commit saga spanning the dashboard, analytics, calendar, subscriptions list, and settings.

Every component had assumptions about styling that broke when I changed the design system.

Lesson: Design tokens and consistent component APIs save you later. I didn't have them. I paid the price.

✂️ Features I Almost Built But Cut

1. Real-Time Collaborative Editing for Families

I almost built live presence indicators (like Notion) for family members editing subscriptions. Cool? Yes. Necessary? No.

Families don't edit subscriptions simultaneously. I was overengineering for a scenario that doesn't exist.

2. Push Notifications via Web Push API

I spent a day on this before realizing the UX for requesting notification permissions is terrible, and email reminders solve 90% of the problem.

Cut it. Moved on. No regrets.

3. Dark Mode Toggle Per-Component

I wanted granular dark mode control. Users just want one toggle. Shipped the simple version.

4. iOS App (for now)

I originally planned iOS and Android together. Reality: I'm one person. Android first, iOS after validation.

🛠️ Tools & Decisions That Saved Me

1. Supabase

Auth, Postgres, Edge Functions, RLS, Storage—all in one. I would've spent months wiring this together with separate services. The RLS learning curve was worth it.

2. shadcn/ui

Copy-paste components I actually own and can modify. No fighting a component library's opinions. The glass-card styling in my dashboard? Just Tailwind on top of shadcn primitives.

3. Zustand over Redux

Minimal boilerplate. I have one store file with slices. State management should be boring.

4. Stripe Checkout (not custom forms)

I almost built custom payment forms. Then I remembered PCI compliance exists. Stripe Checkout handles everything. Worth the small UX tradeoff.

5. Edge Functions for AI

Running Gemini calls in Supabase Edge Functions keeps my Next.js app lean. Cold starts are fine for non-realtime features like AI recommendations.

6. One Repo, One Deploy

No microservices. No separate admin dashboard. Everything lives in one Next.js app. Vercel deploys in 40 seconds.

💡 Advice for Solo Founders

1. Ship the manual version first.

SubBuddy started as manual-only subscription tracking. No CSV import, no bank linking. Users told me what they actually needed. Now I have CSV import because they asked—not because I assumed.

2. Your "MVP" is still too big.

I thought my MVP was lean. Looking back, I could've launched without analytics, without the calendar, without AI insights. The core is: add subscription, see list, get reminder. Everything else is a bonus.

3. Timebox ruthlessly.

I give myself 2-day limits on features now. If it's not done, I either ship what I have or cut it. The CSV import parser isn't perfect—but it works for 90% of cases, and that's enough.

4. Write for your future self.

Every SQL migration has a revert script. Every commit message explains why. Future me has thanked past me multiple times.

5. Talk to users before building.

The family sharing feature exists because users asked. The comparison pages exist because I saw search intent. The onboarding wizard exists because users churned before adding their first subscription.