Marco Arment launched Overcast in 2014 as a free podcast app for iPhone with a single in-app purchase to unlock premium features. Within a year, he had hundreds of thousands of users. He also had a problem that took him two more years to fully understand: the more popular the app became, the more money he lost serving the people who never paid him anything.
The setup is familiar. Build something free, grow fast, convert a fraction of users into paying customers. The ratio that matters, in theory, is whether the revenue from paying users exceeds the cost of serving everyone. In practice, that calculation is almost always wrong in the early stages, and usually wrong in ways founders don’t anticipate.
What Overcast Actually Cost
Overcast is not a trivial app. It streams and downloads audio files, syncs listening position across devices, and at its peak was handling server-side audio processing for a feature called Smart Speed. Every one of those operations costs money, and most of them scale directly with usage rather than with user count.
Arment has been unusually transparent about his economics over the years, writing publicly about the business on his blog. The core tension he described is the same one that traps many consumer app developers: your most engaged users are often your most expensive users, and engagement doesn’t correlate with willingness to pay. The person streaming six hours of podcasts a day through your servers is costing you more per month than the person who opens the app twice a week, and neither of them may have paid you a cent.
In 2015, Arment switched Overcast from a paid unlock model to a patronage model, making everything free and asking users to pay voluntarily. He wrote at the time that this was partly philosophical and partly practical. The practical part was that the one-time purchase model was generating a revenue spike at launch that decayed rapidly, while his costs were more stable month to month. He needed income that looked more like his expenses.
The move worked well enough to sustain the app, but it illustrated a structural issue that anyone running a free consumer app eventually confronts: the cost base is not where most people think it is.
The Three Cost Layers Nobody Budgets For
The obvious costs are compute and storage. You pay for servers, databases, and bandwidth. These are real, and for an audio app they’re meaningful, but they’re actually the easiest part of the cost structure to reason about. Cloud providers give you pricing calculators. The numbers are visible.
The second layer is support and maintenance. A free app with a hundred thousand users generates support email. It generates App Store reviews that require monitoring. It generates bug reports from device configurations you’ve never tested on. Arment was a solo developer, which meant every hour spent on support was an hour not spent building. For a solo operation, this is often the cost that actually determines whether the project survives, not the AWS bill.
The third layer is the hardest to see: opportunity cost and technical debt. A free app with large user numbers creates pressure to maintain backward compatibility, to support older OS versions, to avoid breaking changes that would anger users who aren’t paying you. Arment has written about moments where he wanted to drop features or change behavior but felt constrained by the installed base. The free users, collectively, were making architectural decisions for him.
This dynamic is not unique to solo developers. It scales. Spotify spent years unable to change its free tier terms in meaningful ways because the free user base had become both a negotiating chip with labels and a political liability with investors. The free product had developed its own gravity.
When Free Becomes a Structural Trap
The economics of free apps rest on a conversion assumption that is almost always optimistic. The industry benchmark for freemium conversion to paid is somewhere between two and five percent for consumer apps, and that range has been fairly stable for years. If you budget for four percent and achieve two, your revenue is half of what you modeled while your costs are exactly what you modeled.
Overcast’s patronage model, where Arment simply asked users to pay what they felt was fair, actually produced conversion rates he described as reasonable, but “reasonable” in this context still meant that the large majority of his users contributed nothing financially while consuming bandwidth, storage, and his attention.
The math that makes this work at scale, the math that Spotify and YouTube and every other free-tier business depends on, requires either very low marginal costs per user or very high revenue per paying user. Podcast streaming is not a low-marginal-cost business. Audio files are large. Bandwidth is not free. And the revenue ceiling for a podcast app aimed at enthusiasts is not high enough to build a large organization around.
Arment eventually arrived at a sustainable equilibrium: a small, well-loved app generating enough patronage revenue to justify his time, with server costs that were real but manageable. He got there by staying small deliberately, by not chasing growth for its own sake, and by being honest in public about what the app cost to run. That transparency, paradoxically, probably helped his conversion rate. Users who understood the economics were more likely to pay.
The lesson is not that free apps are bad business. It’s that free is a pricing decision with downstream cost implications that compound over time. The users you acquire for free are not just future revenue opportunities. They are immediate infrastructure load, support burden, and constraint on your product roadmap. As the burn rate conversation in consumer tech often misses, the number that actually matters isn’t how fast you’re spending, it’s the per-unit economics underneath.
What We Can Learn
The Overcast case is useful precisely because it’s small enough to see clearly. The same dynamics operating at Dropbox or Duolingo are harder to parse because they’re buried under funding rounds and accounting complexity.
Three things stand out. First, usage-based costs deserve more scrutiny than user-count costs. An app that charges per seat but has no server-side logic has a very different cost profile than an app doing computation or storage on behalf of users. The free tier for the second type of app is a subsidy you are personally funding.
Second, conversion rate assumptions should be stress-tested at half their expected value before any infrastructure decisions are made. The optimistic scenario is the one that will be in your pitch deck. The pessimistic scenario is the one you should be building for.
Third, pricing your product too low creates its own problems beyond simple revenue math. Free, as a price, signals something to users. It signals that they are not customers. It shapes how they think about the product, how much patience they extend when things go wrong, and how much they feel invested in its survival. Arment’s patronage model worked partly because it asked users to make an explicit choice, which reframed their relationship to the app.
Overcast is still running. Arment still maintains it. The app has outlasted many better-funded competitors that built larger free user bases and then couldn’t figure out how to extract enough revenue to justify their infrastructure. The unsexy lesson is that sustainable free apps tend to be run by people who were honest with themselves, early, about what free actually costs.
