You've built an API. It works. People are using it. Now you want to turn it into a business.
The conventional wisdom says you need enterprise sales, lengthy contracts, and a team of account executives. The conventional wisdom is wrong.
Some of the most successful API businesses were built by solo founders and tiny teams, reaching millions in revenue with nothing but self-serve pricing and good developer experience.
This is the playbook they used.
The Indie Hacker API Advantage
Before we dive in, let's talk about why APIs are perfect for indie hackers:
- Zero marginal support cost: Well-documented APIs don't need hand-holding
- Self-serve by nature: Developers expect to integrate without talking to sales
- Compounding lock-in: Every line of code written against your API is switching cost
- Global from day one: No need for regional sales teams
- 24/7 revenue: Your API makes money while you sleep
The catch? You need to get everything right from the start because you won't have a customer success team papering over problems.
Stage 1: $0 to $10K MRR - Finding Product-Market Fit
Pricing: Start Simple
Don't overthink it. Two tiers is enough:
That's it. No enterprise tier. No usage-based complexity. No "contact us" pricing.
Why so simple?
- Reduces decision friction: Users can evaluate in seconds
- Eliminates support burden: No custom quotes to negotiate
- Forces focus: You're building for one customer type
The 10x Rule
Price your paid tier at 10x the value of the free tier:
| Free tier | Paid tier | Multiplier |
|---|---|---|
| 1,000 requests | 50,000 requests | 50x capacity |
| 7-day data retention | Unlimited retention | ∞ |
| Community support | Email support | Real help |
The gap should be large enough that serious users obviously need to upgrade, but not so large that free users feel deliberately crippled.
Launch Checklist
Before you charge money:
- API works reliably (99%+ uptime for a week straight)
- Docs are complete (quickstart, reference, examples)
- Signup flow works (test it yourself, 10 times)
- Billing works (test charges, refunds, upgrades)
- Rate limits work (test exceeding them)
- Error messages are helpful (users should never see stack traces)
Pro tip:
The fastest path to $10K MRR isn't finding 200 customers at $50/month—it's finding 20 customers who'd pay $500/month. Talk to your free users. Find out what would make them pay 10x.
Stage 2: $10K to $50K MRR - Optimizing the Funnel
You have paying customers. Now it's about conversion optimization.
Add a Middle Tier
Two tiers got you here. Three tiers will grow you:
The middle tier does two things:
- Captures price-sensitive users who balked at $49
- Anchors Pro as reasonable through contrast
Most indie API businesses see 60-70% of revenue come from the middle tier.
Track Your Funnel
Set up analytics to track:
Your conversion rates will look something like:
| Stage | Typical Rate |
|---|---|
| Visitor → Signup | 2-5% |
| Signup → API Key | 50-70% |
| API Key → First Call | 30-50% |
| First Call → Active (week) | 40-60% |
| Active → Paid | 5-15% |
Multiply these out: 1,000 visitors might yield 1-5 paying customers. Now you know how much traffic you need.
Fix the Biggest Leak
Find your worst conversion step and fix it:
Visitor → Signup low? Your value proposition isn't clear. Rewrite your homepage.
Signup → API Key low? Your onboarding has friction. Add a "Generate API Key" button on the first page they see.
API Key → First Call low? Your quickstart is bad. Time yourself following it. Anything over 5 minutes is too long.
First Call → Active low? Your API is confusing. Add better examples, improve error messages.
Active → Paid low? Your free tier is too generous OR your paid tier isn't compelling. Adjust the gap.
Automate Everything
At this stage, you should spend zero time on:
- Issuing API keys (self-serve)
- Answering "how do I sign up?" (obvious UI)
- Handling billing questions (self-serve portal)
- Tracking usage (automated dashboards)
If you're doing any of this manually, stop. Build the automation. Your time is better spent improving the product.
Stage 3: $50K to $200K MRR - Expansion Revenue
You've proven the model. Now it's about growing existing customers.
Add Usage-Based Pricing
Flat-rate worked for early growth. Usage-based captures expansion:
This lets customers start small and grow without hitting walls. A customer who starts at $29 might grow to $200/month as their product succeeds—without you doing anything.
The Proactive Upgrade
Don't wait for customers to hit limits. Reach out proactively:
Customers appreciate being told before they hit problems. And the "you're using a lot" email converts well because it's a compliment disguised as a warning.
Land and Expand
Your best new revenue comes from existing customers. Track:
| Metric | Target |
|---|---|
| Net Revenue Retention | > 110% |
| Expansion MRR / New MRR | > 0.5 |
| Upgrade rate (monthly) | > 3% |
If existing customers aren't expanding, your pricing structure has a problem.
Common mistake:
The classic indie hacker mistake: spending all your time on acquisition when expansion revenue is easier and cheaper. A customer who's already paying trusts you. Selling them more is 5x easier than finding a new customer.
Stage 4: $200K to $1M MRR - Scaling Without a Sales Team
This is where traditional companies hire salespeople. You won't.
The Enterprise Tier (Without Enterprise Sales)
Add an enterprise tier, but keep it self-serve:
Notice what's NOT included: custom contracts, phone calls, procurement meetings. The price is fixed. The features are fixed. Take it or leave it.
You'd be surprised how many "enterprise" customers are happy to swipe a card instead of doing a 6-month procurement process.
Content as Sales
Your sales team is your blog. Write about:
- How to solve problems your API solves: attracts people who need you
- Comparisons with alternatives: captures people evaluating options
- Customer use cases: shows social proof without sales calls
- Technical deep-dives: establishes credibility
One well-ranking blog post can generate more leads than a salesperson.
Build in Public
The indie hacker community responds to transparency. Share:
- Revenue milestones (with Stripe screenshots)
- Technical decisions and tradeoffs
- Mistakes and lessons learned
- Roadmap and upcoming features
This builds trust and generates word-of-mouth that no marketing budget can buy.
The Tech Stack That Scales
Here's what you need to run a $1M API business as a solo founder:
Core Infrastructure
| Component | Recommendation | Cost |
|---|---|---|
| API Gateway | Zuplo | Usage-based |
| Backend | Cloudflare Workers / AWS Lambda | Usage-based |
| Database | PlanetScale / Supabase | $29-99/month |
| Billing | Stripe | 2.9% + $0.30 |
| Auth | Clerk / Auth0 | $25-100/month |
| Monitoring | Axiom / Datadog | $0-100/month |
Developer Portal
Don't build your own. Use a platform that provides:
- Auto-generated API documentation
- Self-serve API key management
- Usage dashboards
- Stripe billing integration
This saves 3-6 months of engineering time and gets you a better result.
Support
For up to $200K MRR, you can handle support yourself if you:
- Have excellent documentation (reduces tickets)
- Use async channels (email/Discord, not phone)
- Set clear expectations (24-48 hour response, not instant)
Past $200K, consider one part-time support person or a community moderator.
Financial Targets by Stage
| Stage | MRR | Customers | ARPU | Monthly Growth |
|---|---|---|---|---|
| 1 | $0-10K | 50-200 | $50 | 20-30% |
| 2 | $10-50K | 200-700 | $70 | 15-20% |
| 3 | $50-200K | 700-2000 | $100 | 10-15% |
| 4 | $200K-1M | 2000-5000 | $200 | 5-10% |
Notice the ARPU increases as you add tiers and usage-based pricing. This is the expansion revenue working.
Common Mistakes (And How to Avoid Them)
Mistake 1: Pricing too low
"I'll charge $9/month to get lots of customers!"
No. You'll get customers who don't value your service and churn when they encounter any friction. Price reflects value. If your API is valuable, charge like it.
Mistake 2: Building custom features for specific customers
"This customer will pay $5,000/month if I just add this one feature..."
Maybe. But now you're maintaining a feature for one customer. Your roadmap gets hijacked. Your codebase gets messy. And when that customer churns, you're stuck with the technical debt.
Build features that benefit multiple customers or politely decline.
Mistake 3: Ignoring documentation
"I'll write docs later when I have more time."
You won't have more time. And every hour of documentation saves 10 hours of support. Write docs first, or at least in parallel with building.
Mistake 4: Overcomplicating billing
"We need 7 tiers, usage-based pricing, volume discounts, annual prepay..."
Stop. You need enough billing complexity to capture value, and not one feature more. Every billing option is a decision point where customers can abandon.
The Timeline
Realistic timeline for a solo founder with a working API:
| Milestone | Timeline |
|---|---|
| First paying customer | Month 1-2 |
| $1K MRR | Month 3-4 |
| $10K MRR | Month 6-12 |
| $50K MRR | Month 12-24 |
| $200K MRR | Month 24-36 |
| $1M MRR | Month 36-48+ |
This assumes you're working on it consistently and the market exists. Some APIs reach $1M faster; many never get there. The market matters more than execution.
Conclusion
Building a million-dollar API business without a sales team isn't just possible—it's increasingly the norm. The tools and platforms available today let solo founders ship products that rival funded startups.
The playbook is simple:
- Start with two tiers (free and paid)
- Track your funnel, fix the biggest leak
- Add tiers and usage-based pricing as you grow
- Expand existing customers instead of only chasing new ones
- Let content and community do your selling
You don't need enterprise sales. You don't need a marketing team. You need a good API, clear pricing, and the patience to optimize relentlessly.
$1M is a lot of money. But it's only 2,000 customers paying $40/month average. Or 500 customers at $170/month. Or 100 customers at $800/month.
Your API probably has more than 100 potential power users who'd pay $800/month for the right solution.
Go find them.