Build vs Buy: A Practical Guide for Indie Hackers

You are one person. Maybe two. You have a product to ship, customers to support, and a marketing page that still says "Coming Soon" in three places. And now you need to decide: should you build this feature yourself, or pay someone else for it?

This decision is the single biggest time-allocation mistake indie hackers make. Build the wrong thing and you waste weeks. Buy the wrong thing and you waste money while adding a dependency you don't control.

Here's a framework that actually works when you're a team of one.

The Default Should Be "Buy"

This is counterintuitive for most developers. We became indie hackers because we like building things. But building is the most expensive thing you can do. Your time is your only resource, and every hour spent building infrastructure is an hour not spent on your core product.

The math is simple. If a tool costs $20/month and saves you 40 hours of building plus 2 hours/month of maintenance, you'd need to value your time at less than $0.50/hour to justify building it yourself.

So the default answer is: buy. Then ask yourself if there's a compelling reason to override that default.

When to Build Instead

There are exactly four situations where building makes more sense:

1. It's Your Core Differentiator

If the feature is the reason customers choose you over competitors, you should own it completely. Stripe built their own payment processing because payment processing IS their product. You should not build your own payment processing.

The test: Would a customer switch from a competitor to you because of how you implement this specific feature? If yes, build it. If no, buy it.

2. No Good Tool Exists

Sometimes the market hasn't caught up. Maybe you need a very specific integration, or the available tools don't support your use case. In this case, building is fine — but set a time cap. If you can't build a working version in one week, the scope is wrong.

3. The Tool Creates Unacceptable Lock-in

If switching away from a tool would require rewriting a core part of your application, think carefully. Database hosting? Fine — your data is portable. A proprietary workflow engine that stores all your business logic? Dangerous.

4. The Cost Scales Badly

Some tools charge per user, per event, or per API call. If you can see a future where the tool costs more than your revenue, that's a real problem. Look for flat-rate alternatives first. If none exist, consider building.

A Real Example: Feedback Collection

Let's say you want to add a feedback widget to your SaaS. You have three options:

Option A: Build it yourself. You create a form, an API endpoint, a database table, a dashboard to view submissions. You add email notifications. Then users ask for sentiment tracking, so you add that. Then they want a public roadmap. Conservatively: 3-4 weeks of work, then ongoing maintenance forever.

Option B: Use a complex enterprise tool. You sign up for a $79/month feedback platform. It has 200 features you don't need. You spend a week configuring it. You're now paying $948/year for a tool that's overkill.

Option C: Use a focused tool. You drop two lines of code into your site, and feedback starts flowing in. The tool costs $0-20/month and handles the widget, dashboard, sentiment, roadmap, and changelog. You spent 5 minutes instead of 4 weeks.

Option C is almost always the right answer for indie hackers. Tools like Palmframe exist precisely to solve this — a two-line install, a free plan for getting started, and a focused feature set that doesn't try to do everything.

The Hidden Cost of Building

When you build something, you're not just paying the upfront cost. You're signing up for:

• Bug fixes — users will find edge cases you didn't think of
• Security patches — especially for anything user-facing
• Feature requests — "can the feedback form also do X?"
• Infrastructure costs — hosting, monitoring, backups
• Opportunity cost — every hour maintaining this is an hour not spent on growth

Multiply all of that by "forever." That's the real cost.

The Hidden Cost of Buying

It's not all roses on the buy side either:

• Dependency risk — the tool could shut down, raise prices, or degrade
• Integration overhead — some tools are harder to integrate than they claim
• Feature gaps — you might need something the tool doesn't do
• Data portability — can you export your data if you leave?

Mitigate these by choosing tools with APIs, data export, and transparent pricing.

A Decision Checklist

Before building anything, run through this:

1. Is this my core differentiator? If no → lean toward buying
2. Does a good, affordable tool exist? If yes → buy it
3. Can I install it in under an hour? If yes → definitely buy it
4. Will the cost scale reasonably? If yes → buy it
5. Can I export my data later? If yes → safe to buy

If you answered "no" to most of these, building might make sense. But be honest — developers are biased toward building. Challenge your "no" answers.

The Indie Hacker Stack

Here's a practical list of what to buy vs build for a typical SaaS:

Buy (almost always):

• Authentication (Clerk, Auth0, or framework-native)
• Payments (Stripe, Lemon Squeezy)
• Email (Resend, Postmark)
• Feedback collection (Palmframe)
• Error monitoring (Sentry)
• Analytics (Plausible, PostHog)
• Hosting (Railway, Fly.io, VPS)

Build (it's your product):

• Your core feature — the thing users pay you for
• Custom workflows specific to your domain
• Integrations that tie your product together

Case-by-case:

• Admin dashboards (build if simple, buy if complex)
• Landing pages (build if you enjoy it, use a template if not)
• Background jobs (framework-native is fine for most cases)

The One Rule

When in doubt, ask yourself: "If I spend this week building, will my customers notice?"

If the answer is no — if you're building backend infrastructure, internal tools, or features that already exist elsewhere — buy it and spend that week on something customers will actually pay for.

Your competitive advantage is not your feedback widget, your auth system, or your email pipeline. It's the core thing only you can build. Spend your time there.