The pricing question
Every app we ship faces the same opening question: how does it make money? There’s no universal answer, but there is a framework we use that has saved us from a lot of bad first instincts.
The framework is simple to state. We start from what the app costs us to keep running and what the person using it actually gets, and we look for the model where those two line up. Not the model that would earn the most in a spreadsheet, and not the one a competitor happens to use. The one that’s honest about the shape of the work.
We’re a small, self-funded studio, so this isn’t abstract. There’s no investor money to cover a model that doesn’t pay for itself, and no growth team to paper over one that annoys people. Whatever we pick has to work on its own terms.
One-time purchase
For apps where the value is delivered in the moment of use and doesn’t require ongoing infrastructure from us — image converters, calculators, simple utilities — we charge once. The user pays, owns the app, and we move on.
“Move on” is a slight exaggeration. A one-time app still needs updates when the operating system changes, and those updates aren’t free. What we’ve learned is to price with that in mind rather than at the lowest number a store will accept. A small desktop utility that does one job on your own machine, with nothing on our side running up a bill every month, is the natural fit for this model.
Subscription
For apps with real ongoing cost on our side (sync servers, AI inference, regular content updates) — we subscribe. We try to set the price at roughly what we’d need from the median user to break even, not what we could maximally extract.
The test we apply is whether we can explain, in one sentence, what the monthly money pays for. If the answer is “a server that keeps your data in sync across devices” or “forecasts we have to fetch and process every day,” a subscription is fair. If the answer is “because recurring revenue looks better,” it isn’t. An app that needs fresh data to stay useful is exactly the kind of case where we weigh a subscription seriously.
Free with ads
Rare. We only do it when the app is so casual that even a small paywall would kill discovery, and when we’ve found an ad partner that doesn’t track users across apps. Both of those conditions are getting harder to meet every year.
We don’t rule ads out. They’re a legitimate way to fund software people wouldn’t otherwise pay for, and for some apps they may turn out to be the right call. What we’re careful about is placement and partners: an ad that interrupts the one thing the app is for is a cost the user pays, even if it never shows up on a receipt.
Freemium
The model in between: a free app that’s genuinely useful on its own, with a paid upgrade for people who want more. This is the one we find hardest to get right. Draw the line too low and the free version feels like a demo. Draw it too high and nobody upgrades, and the app can’t sustain itself. When we use it, the rule is that the free tier has to be something we’d happily recommend by itself.
Free
For tools we want to exist regardless. A few of our smaller apps fall here. They’re funded by the paid ones.
What we got wrong
Our first instinct was to decide pricing at the end, once the app was built. That was a mistake. Pricing shapes the product: a subscription app needs a reason to come back, a one-time app needs to be complete on day one, a free app needs to be cheap to run. Now we pick the model before the first screen is designed, and we revisit it honestly if the app turns out to be something different from what we planned.
None of these choices is permanent. An app can move between models as it grows and its costs change — and when one does, we’ll say so plainly and explain why.