Why Every Indie Hacker Needs a CRM (And Why Spreadsheets Don't Scale)

You launched your first product, got a few hundred users, and opened a Google Sheet to track them. It worked. Then you launched a second product. Then a third. Now you have three sheets, none of them agree on who your actual customers are, and you just emailed the same person twice about two different products without knowing it.

This is the spreadsheet wall. Every indie hacker hits it eventually. This post explains exactly when you'll hit it, what you're losing before you do, and what a real customer database gives you that spreadsheets never can.

The spreadsheet works until it really doesn't

Spreadsheets are genuinely good for early-stage tracking. They're fast to set up, flexible, and you already know how to use them. When you have under 200 customers in a single product, a spreadsheet is probably fine.

But indie hackers rarely stay in one product. The whole point of the model is to build, launch, iterate, and occasionally spin up something new. The moment you have more than one product with paying users, the spreadsheet model starts to crack.

Here's what happens in practice: You have Product A with 300 users in Sheet A. You launch Product B and start Sheet B. Some of your Product A customers sign up for Product B. Now you have duplicate records with slightly different email formats, different naming conventions, and no way to know that "john.doe@gmail.com" in Sheet A is the same person as "johndoe@gmail.com" in Sheet B.

You don't know who your best customers are — the ones buying multiple products. You don't know when someone who used Product A also started using Product B. You don't know which product attracted a particular customer first.

What you're actually losing without a CRM

The damage from unorganized customer data isn't dramatic — it's slow and cumulative. Here's what slips through the cracks:

• Cross-sell opportunities. Your best customers are the ones already trusting you. But if you can't see who uses multiple products, you're guessing at who to reach out to.
• Churn signals. If a paid customer goes quiet, do you know? Spreadsheets don't have a "last_activity_at" column that updates automatically.
• Duplicate communication. Emailing the same person from two products without knowing they're the same person is unprofessional and annoying to them.
• Historical context. When a customer emails with a question, you can't see their full history across your products without opening three different sheets.
• Time. Manual data entry into spreadsheets takes time you could spend building.

The three signals that you've outgrown spreadsheets

Not everyone needs a CRM immediately. Here are the three concrete signals that it's time:

Signal 1: You have more than one product with paying users. This is the most important one. One product can live in a spreadsheet. Two products means you need a merge strategy. Three or more means you need a database.

Signal 2: You've started manually copying data. When you find yourself exporting from Stripe, pasting into a sheet, then cross-referencing with another sheet — that's a sign you've built a manual ETL pipeline. A CRM with an SDK makes this automatic.

Signal 3: You can't answer basic questions quickly. "How many people pay for both my products?" "Who has been inactive for 30 days?" "Which plan is most common?" If answering these requires 10 minutes of spreadsheet gymnastics, you've outgrown the tool.

Why traditional CRMs don't fit indie hackers

HubSpot, Salesforce, Pipedrive — these are sales team tools. They were designed for companies with multiple salespeople, a defined pipeline process, and a dedicated person to manage the CRM. They cost $50–500/month per seat. They take weeks to configure. They assume you have leads to qualify, deals to close, and a CRM administrator.

Indie hackers don't work that way. You want customers to appear in a table automatically when they sign up. You don't want to manually create contact records. You don't have a pipeline — you have products that people are either using or not using.

The mismatch is real. Traditional CRMs make you do the work. Developer-first CRMs automate the work. You call identify() when someone signs up, and they appear. That's the right abstraction for a solo developer.

What a developer-first CRM looks like in practice

The right CRM for an indie hacker has a few core properties:

• SDK-first. Customer data comes from your app's server side, not from manual entry. You instrument your signup flow once, and it runs forever.
• Email as the merge key. One customer email = one row, regardless of how many products they use. No duplicates.
• Multi-project aware. Designed from the ground up to handle multiple products under one account.
• Simple pricing. Flat monthly rate, not per-seat. Solo developers shouldn't pay enterprise prices.
• Filterable dashboard. Filter by project, status, activity date. Basic, but that's all you need.

The real cost of waiting

The argument for "I'll set up a CRM later" makes sense until you realize that customer data is one of the few things that compounds over time. Every week you don't capture last_activity_at, you're losing churn signal. Every month you don't track which product customers came from first, you're losing acquisition data.

Setting up a basic CRM integration takes under an hour with the right SDK. You add two lines to your auth flow and get a populated customer table. The upfront cost is tiny; the long-term value is significant.

Starting small: what "good enough" actually means

You don't need a full-featured CRM with email campaigns, automation, and AI scoring. What you actually need:

• A table showing all your customers across all products
• The ability to filter by project, status, and date
• Automatic data capture from your app's backend
• A customer profile showing their product history
• CSV export when you need to take action

That's it. That covers 90% of what indie hackers actually need from customer data. Everything else is scope creep.