--- slug: pricing-your-indie-app title: "Pricing Your Indie App: A 5-Minute Decision Guide" excerpt: "Indie app pricing doesn't have to take a week of spreadsheets. Here are the five real models, how to pick one fast, and why you can always change it later." primaryKeyword: "indie app pricing" publishedAt: 2026-05-02 readingTimeMin: 8 author: "Robert Boylan" tags: - pricing - indie-dev - app-planning - revenue-model - vibe-coding --- You have a working app. Maybe you built it in Lovable over a weekend, or you and Claude Code went back and forth for a week until it did what you wanted. Either way, it exists. Now someone asks: "How much does it cost?" And you freeze. Pricing an indie app is one of those decisions that feels like it needs a spreadsheet and three business books behind it, so founders delay it, or they copy whatever the last app they used was doing without thinking about whether that model fits. This post cuts through it. Indie app pricing has five real options. You can pick the right one in five minutes if you know what to ask yourself. ## The five indie app pricing models and when each one actually makes sense ### Free with ads The app is free to download and use. Revenue comes from advertising, either banner ads or video interstitials (the "please wait 5 seconds" kind that makes people never open an app again). This works when: you're targeting a wide consumer audience, usage is daily or close to it, and the content itself is the draw (news, games, audio, short video). Think a free puzzle game, a weather app, a news reader. The honest tradeoff: ad revenue is tiny unless you have hundreds of thousands of users. App stores also increasingly flag heavy ad implementations at review, and fighting that while building the product is exhausting. For most indie apps under 50k monthly actives, ad revenue won't cover a cup of coffee. If your app is a utility, skip this entirely. If you're playing a volume game with a broad consumer product, it's legitimate, but go in knowing the maths require scale. ### One-time purchase User pays once. They own it. No recurring anything. This works beautifully for utility apps: file converters, productivity tools, games, writing tools, anything where the core value is a single piece of capability rather than an ongoing service. People are conditioned to pay once for desktop apps and iOS utilities, and there's almost no churn (churn is when paying customers cancel, which directly hurts your monthly revenue). One-time purchases have zero churn by definition. The tradeoff is obvious: no recurring revenue. Your MRR (monthly recurring revenue, the predictable monthly income from subscriptions) is zero, which makes planning hard. Some founders solve this with "paid upgrades" for major new versions, which works fine as long as you're honest about what constitutes a real upgrade. Good fit: desktop tools, mobile utilities, single-player games, apps that do one focused thing extremely well. ### Freemium (free tier plus paid tier) A portion of the app is free forever. Premium features cost money, either as a monthly subscription or a one-time upgrade. Spotify is the famous example. Notion uses this. Draftlytic uses it too (the free tier lets you try the core flow before you need to [look at a paid plan](/pricing)). Freemium works when there's a natural ceiling that free users will hit, and that ceiling feels fair rather than artificial. "You can read 5 articles free, pay for unlimited" is a ceiling that feels reasonable. "You can use 3 features out of 20 but the other 17 are locked" feels annoying. The risk most people underestimate: free users are real infrastructure costs. Storage, compute, support emails. If you have 10,000 free users and 50 paying ones, you need those 50 to cover the costs of everyone. Do the maths before assuming a large free tier is free marketing. Good fit: apps with a clear "power user" distinction, where casual users get real value from the free tier but heavy users obviously need more. ### Subscription User pays monthly or annually. They keep access while they pay. Subscription is the default model for most SaaS (software as a service, basically any software you access via a browser or app that runs on someone else's servers). The appeal is recurring, predictable revenue. The bar it raises is that you need to keep delivering value every month, or people cancel. If your app does one thing and then it's done, subscription makes users feel like they're paying rent on a house they already built. Subscription works when usage is ongoing and the value accumulates over time: project management tools, analytics dashboards, social scheduling, anything where the app is part of your weekly workflow. More on free trials vs free tiers further down, because the difference matters and most people muddle it. ### Credits / pay-as-you-go (the AI-era model) This one is newer. You buy a bundle of credits. Each action you take costs some. When you run out, you top up. It's how most AI-powered features get priced now, because the underlying cost is per-API-call rather than per-month. This works when cost-per-use varies a lot across users. A power user who runs 50 AI-generated plans a month costs fifty times more to serve than someone who runs one. Flat subscriptions punish you when heavy users dominate. Credits let price track cost. The downside: some users find pay-as-you-go psychologically exhausting. If your users are professionals expensing to a company, they may prefer a flat subscription. If they're indie devs watching their costs carefully, credits feel fair. Draftlytic uses freemium plus credits, because [planning an app](/blog/vibe-coding-why-planning-matters) is one of those tasks you might do once for one project and ten times for another. Flat pricing didn't fit the usage pattern. ## How to pick: one question does most of the work Ask yourself: how often does a typical user actually use this? Daily, every day without fail: subscription. The value keeps arriving and the price feels justified because the app is woven into the routine. A to-do app, a time tracker, a journaling tool. Weekly or a few times a month: freemium or a light subscription. The usage is real but occasional. A free tier with an upgrade path works here because users need time to feel the value before committing. Occasional but intense: one-time purchase or credits. Someone who opens a file converter twice a year is never going to feel good about a monthly subscription for it. Either charge them once and let them own it, or charge them per use and call it done. Monthly or less but high stakes: subscription can still work here if the stakes justify it. A legal document tool used once a month is still worth paying for if the alternative is a lawyer. A secondary question helps narrow it: are you building for professionals or consumers? Professionals expense subscriptions and tolerate monthly charges. Consumer apps face more friction on recurring pricing because the cost comes from personal budgets. Consumer apps tend to do better with one-time purchases or freemium; professional tools can hold higher subscription prices. ## Real examples so you can pattern-match A **language learning app** (daily, consumer): freemium with a subscription upgrade. Duolingo's model works because the habit is daily and the free version is genuinely good. A **markdown editor for developers**: one-time purchase. iA Writer, Typora. You buy it once and use it forever. Developers trust this model. A **client reporting tool for freelancers**: subscription. Used monthly, high value, professionals who can justify the cost. An **AI-powered writing assistant**: credits or freemium plus credits. The underlying cost is per API call, so credits track your real cost. Give users some free credits to experience the product, then charge for more. A **mobile game**: free with ads or a one-time premium version. The "free with ads / $2.99 to remove ads" IAP (in-app purchase) is well understood by consumers and converts reasonably. When you're deciding, also look at what's already working in your category. Not to copy blindly, but because [choosing the right approach means understanding what your users are already used to paying for](/blog/developer-vibe-coder-or-founder). You're not just competing on features. You're competing on the mental model users bring to the purchase. ## Free trial vs. free tier: the decision most people muddle These are not the same thing, and choosing the wrong one is a real mistake. A **free trial** gives users full access for a fixed period (7, 14, or 30 days). At the end, they pay or they leave. Works well when the value is obvious quickly and you want a fast decision. Good for professional tools. A **free tier** is a permanent, limited version of the product. Works well when word-of-mouth matters or when the time-to-value is long (users need months to feel the full benefit). The mistake most indie builders make: they offer a free tier for growth, but make it so limited that no one recommends it. If your free tier doesn't deliver a genuinely complete experience for some user, it's just a trial with no expiry date. A good free tier has a real user inside it: someone who could use the product forever at the free level, but will eventually want more. Design around them, not around how little you can give away. ## Pricing is not a permanent decision The anxiety around indie app pricing comes from treating it like it's carved in stone. It isn't. Basecamp went from subscription to one-time. Sketch went the other direction. Apps change pricing models all the time. Existing users complain; almost all of them live. What matters: picking something defensible right now so you can ship and get real data. "Defensible" means you can explain why the price is fair, and you won't lose money serving users at that price. That's the bar. Take five minutes with the usage question above and the model list in this post. Pick the closest fit. Ship. The pricing conversation gets much easier once you have 50 users and actual numbers to look at. Writing down the revenue model in your spec before you build keeps it from becoming a debate every time you open the project. Draftlytic captures it as part of the project plan, so when you hand the spec to Cursor, Lovable, v0, or Bolt.new, the pricing logic is already in there. One less thing to re-explain from scratch. Pick a model. Ship. Revisit in three months with real numbers.