SECTION 01
How Solo App Dev Revenue Actually Works — Think Gross Profit, Not Monthly Revenue
You see indie developers posting about their monthly revenue all the time, but monthly revenue alone is misleading. What actually determines whether a service is worth continuing is gross profit — revenue minus fixed and variable costs.
The framework is simple: revenue, fixed costs, variable costs, and gross profit. Server fees and domain costs are fixed; payment processing fees and app store commissions are variable. Tracking these four numbers monthly gives you a clear picture of your service's financial health.
From my experience building over forty services, only a handful ever generated meaningful revenue. Most never reached any real monthly income. But having the habit of managing by gross profit meant I could make continue-or-quit decisions based on numbers, not emotions.
A common trap is assuming any revenue means things are going well. Once you subtract fixed costs, you might discover you're actually losing money. Stop celebrating monthly revenue and start checking whether gross profit is positive or negative — that's the first step.
SECTION 02
How Low Can Fixed Costs Go — The Cost Side Determines Your Break-Even
Fixed costs in indie development typically include infrastructure, domains, payment processor base fees, and third-party service subscriptions. Without mapping these out before you start, costs accumulate before any revenue appears.
Here's how to minimize each category:
- Hosting: Use services with generous free tiers so you don't pay until traffic grows
- Database: Choose managed services with sufficient free quotas
- Authentication: Use open-source auth libraries to avoid monthly auth service fees
- Domains: Pay annually but calculate the monthly equivalent for budgeting
For new services, I default to a lightweight stack like Vercel, Neon, and Auth.js. Spending on heavy infrastructure before knowing if a project will generate revenue simply isn't rational. Getting fixed costs close to zero means even small amounts of revenue can turn profitable quickly.
The biggest advantage of low fixed costs is that your decision window expands. If you're burning thousands on servers, you'll panic and shut down prematurely. Near-zero costs let you calmly analyze data and iterate. The break-even point is determined by your cost side, not your revenue side.
SECTION 03
Conversion Rates and Break-Even — The Reality of Subscriptions, One-Time Purchases, and Ads
Indie dev revenue models generally fall into three categories: subscriptions, one-time purchases, and advertising. Each fundamentally changes how you design and operate your service, so you need to decide before launch.
Here's a quick comparison:
- Subscriptions: Stable recurring revenue potential, but high churn kills LTV. You must continuously deliver value worth paying for every month
- One-time purchases: Lower barrier to entry for users, but revenue drops to zero when new acquisitions stop
- Ads: No payment friction means more users, but you need massive traffic to break even
To calculate your break-even point, the sum of fixed and variable costs must be exceeded by user count multiplied by conversion rate. For subscriptions, ask what percentage of active users will pay. For ads, ask whether revenue per pageview covers your costs.
The hard truth is that converting free users to paid is extremely difficult. If you get the timing or presentation of your paywall wrong, users simply leave. Payment flows should be designed into the product from day one, not bolted on afterward.
For subscription models, controlling churn matters more than acquiring new users. Investing in retention mechanisms for existing users builds gross profit more reliably than constantly chasing new sign-ups.
SECTION 04
Designing the Free-to-Paid Conversion Funnel
Improving conversion rates requires engineering the moment when users feel paying is worth it. Simply locking features behind a paywall isn't enough — if users can accomplish what they need for free, there's no reason to upgrade.
Effective conversion funnels share common traits:
- Let users experience value for free first, then offer deeper value behind the paywall
- The best time to prompt payment is right after a user achieves their first success
- Display pricing in a clear, comparable format that builds conviction, not just a sense of savings
A frequent mistake is launching free with plans to "add monetization later." Users who've gotten used to free access strongly resist paying afterward. Designing the boundary between free and paid tiers from the start significantly reduces psychological friction.
Another critical factor is minimizing steps to payment. Every extra screen or confirmation between interest and checkout increases drop-off. Keep the funnel simple and frictionless — that's the rule.
SECTION 05
When Revenue Stalls — What to Fix First
When revenue plateaus, the first thing to question is your marketing funnel, not your code. Improving code quality doesn't help if users don't know your service exists.
There are three levers to pull:
- Acquisition: Are your channels for reaching new users actually working? Check search traffic, social media, and word-of-mouth referrals individually
- Conversion: Are visitors signing up and paying? Look for drop-off points in your landing page and payment flow
- Average revenue per user: Is there room to increase what each user pays? Consider plan restructuring or premium add-ons
Among these three, acquisition almost always has the biggest impact. No amount of conversion or pricing optimization matters if the total number of visitors is too small. Start with analytics, identify which channels have growth potential, and focus there.
A common pattern among technical founders is spending too much time on UI polish or new features. Product quality matters, but the assumption that "if you build it, they will come" rarely holds true. Get the improvement order wrong, and a great product stays invisible.
The key insight is to work through these levers in order: acquisition first, then conversion, then pricing. Jumping straight to pricing optimization with minimal traffic is optimizing the wrong thing.
SECTION 06
The Portfolio Approach — Running Multiple Services in Parallel
Going all-in on a single service isn't inherently wrong, but in indie development, the default assumption should be that you don't know what will work. Building multiple small services and shifting resources toward the ones that gain traction is a more realistic strategy.
The benefits of a portfolio approach include:
- No single failure is fatal. Risk is distributed across multiple projects, both financially and psychologically
- Data and lessons from each service inform your next decisions
- Your hit rate improves. You can't predict what resonates until you ship
However, parallel operation only works if each service's running costs are near zero. Without the lightweight stack approach mentioned earlier, maintenance costs alone will push you into the red. Low deployment friction is the foundation that makes the portfolio model viable.
The critical principle is not treating all services equally. Keep underperforming services on minimal maintenance and concentrate on the ones showing signs of life. Trying to nurture everything equally means nothing gets the attention it needs to break through.
SECTION 07
Continue, Cut, or Sell — Deciding When to Walk Away
One of the hardest decisions in indie development is knowing when to stop working on a service. The more attached you are, the longer you delay the decision — but there's no virtue in persistence for its own sake. The goal is generating revenue.
The decision framework I follow looks like this:
- First, try multiple improvement tactics: switch acquisition channels, redesign the payment flow, narrow the target audience
- If the same approach gets no response, move to a different approach. Pivoting is always on the table
- If nothing works, evaluate shutdown versus sale
There are cases where continuing despite small revenue makes sense. If a small group of users is actively and consistently using your service, there may be room to grow through better conversion or retargeting. But if even free users aren't sticking around, the market signal is clear — it's time to move on.
Before choosing shutdown, consider selling. Even services with modest ongoing revenue can attract buyers. I sold a service that was generating a consistent monthly income through an M&A deal — the key factor was that it had a track record of sustained revenue, which made it attractive to a buyer.
Revenue being small doesn't mean value is zero. Having "build → grow → sell" as a cycle in your mental model transforms quitting from "throwing away" into "recovering value." Whether you have this perspective or not significantly changes the quality of every decision along the way.
SECTION 08
Revenue Recovery Goes Beyond Monthly Income
When people think of indie dev revenue, they picture monthly subscription or ad income. But the recovery routes extend well beyond that — M&A exits, consulting opportunities, and career leverage from your technical reputation all count.
Consider these alternative recovery methods:
- M&A sale: Transfer a service with recurring revenue for a lump-sum payment
- Consulting and freelance work: Leverage domain expertise gained from running a service into paid engagements
- Personal branding: Being known as "the person who built X" creates trust that leads to new opportunities
Even if monthly revenue is negative, the knowledge and credibility gained from building a real service can generate income elsewhere. For indie developers, having a live, functioning product in your portfolio is an asset in itself.
That said, don't over-rely on indirect benefits. The primary goal should always be making the service itself profitable. "It's good for my brand" is not a valid reason to keep subsidizing a losing project indefinitely. Be honest about the distinction between strategic investment and wishful thinking.
SECTION 09
What Makes a Product Sell Isn't Tech or Ideas
After years of building and shipping, I've come to believe that what makes a product sell is neither technical excellence nor a novel idea. There's something in between — a fit between the user's problem and the value you deliver — that determines whether revenue materializes.
Put differently, users don't care about your tech stack. They care whether their problem gets solved. Technical sophistication is invisible to them; the only thing that triggers a payment decision is perceived value for their specific need.
To find this fit, you can take concrete steps:
- Talk to potential users before launch. Validate that your assumptions match actual needs
- Watch how early adopters use your product and pay attention to unexpected usage patterns
- Ask paying users directly: "Why did you decide to pay?"
This "something" doesn't reveal itself after one success. It only emerges through repeated failure. But actively trying to articulate what it is — rather than leaving it as an instinct — meaningfully changes your odds of monetizing the next service.
SECTION 10
A Design Philosophy for Realistically Building Solo App Dev Revenue
Looking back at everything covered, the design philosophy for accumulating indie dev revenue comes down to "ship small, judge by gross profit, and move on quickly if it's not working." This unglamorous cycle matters far more than any single success story.
Here are the principles to keep in mind:
- Push fixed costs toward zero. Maximize the time you have to make decisions
- Design the revenue model upfront. Don't retrofit payment flows
- Manage by gross profit, not monthly revenue. Check whether you're in the black every month
- Improve in order: acquisition → conversion → pricing
- Keep shutdown and sale as live options. Continuing isn't always the right answer
Monetizing indie projects is not a one-shot endeavor. It's a process of building, failing, and refining your judgment each time. The knowledge accumulated through that process is the most powerful asset you carry into your next project.
One final thought: not generating revenue isn't failure. Failure is repeating the same mistakes without learning. As long as you're tracking gross profit, iterating, making decisions, and moving forward, your indie dev revenue will accumulate — slowly, but surely.
