Team of One Aug 22, 2026

Pricing Is Not a Spreadsheet Problem

You've shipped the app, killed the crashes, and you're staring at a blank In-App Purchases tab. New Team of One is about how a studio of one actually decides what to charge, and why copying competitor pricing just copies their mistakes.

I shipped Feeder Rater and immediately opened the In-App Purchases tab. The app worked. The crashes were gone. And I had no idea what number to type in.

Nobody warns you this is its own project. You budgeted time for the paywall screen. You didn't budget time for deciding what belongs behind it.

I've now priced seven products across iOS, Android, and web. I've landed in three different places for it, free with ads, one-time paid, and subscription, sometimes for the same kind of app. That inconsistency used to bother me. It shouldn't have. The mistake was never picking the wrong model. It was picking a model before I knew what I was actually selling.


When does it actually earn its money

Every pricing decision I've made eventually comes down to one question: when does this thing actually earn its money?

A tool earns it the first time it solves the problem. Feeder Rater exists to answer one question fast. If it does that once, it's already paid for itself, so a small one-time price fits, or nothing at all with a light ad. Charging a subscription for something people open twice a month is asking them to pay rent on a hammer.

A habit earns it over time. Something like Knit-Knot lives or dies on whether people come back tomorrow, and the value builds the longer they stick around. That's the real case for a subscription, not "recurring revenue" as a business goal but recurring use as the actual product experience. If nobody's opening it in week three, a subscription just finds that out slower.

A small utility has value that's real but doesn't grow past a certain point, something you'd open for ten seconds to get an answer and close again. This is where free-plus-ads quietly wins. You're not trying to squeeze more out of it than it's worth. Try to monetize a quick one-off tool like it's a habit product and you'll end up reading about it in the reviews.

I didn't have any of this worked out when I shipped the first two apps. What I had instead was "what do the other apps in this category charge," which sounds like research but isn't really the same question.


Copying competitor pricing copies their mistakes too

Early on I'd open five similar apps, write down their prices, and land somewhere in the middle. Felt responsible at the time. It's really just outsourcing a decision you haven't made yet, and it drags in whatever's already wrong with the category. Some of those apps are guessing too. Some are subsidized by ad money or funding you don't have. A few are priced high on purpose just to make their "pro" tier look reasonable next to it.

What worked better for me was pricing against my own support load instead of the market. At this scale I know roughly how many emails a product generates a month, because I'm the one answering them. That's a real number. A market average isn't.


The subscription trap is a solo problem specifically

Subscriptions look like the grown-up choice. Recurring revenue, predictable, "how real businesses do it." Fine if you've got a team and a roadmap and someone whose job is retention. For one person, a subscription is a monthly promise to keep improving something forever, and the app stores hold you to it whether you've got the bandwidth or not.

I almost put a subscription on a product that was, honestly, finished. Stable, feature complete, nothing left that anyone was asking for. A subscription on a finished product is a small lie you tell every month. A one-time price on the same product is just true.

My rule now: if I can picture the roadmap running out, it's not a subscription. If the value depends on me actually continuing to work on it, new content, ongoing moderation, whatever, then a subscription is honest, because I'm making a real promise.


Free isn't actually free

The apps I made free with ads didn't skip the pricing decision. They just moved the cost from the user's wallet to my inbox. Ad SDKs, mediation, fill rates, the occasional ugly ad that ruins a clean screen, and a whole category of "why is there an ad here" emails a paid app never generates. It's a real cost. It just gets paid in my time instead of their money, and I'm not convinced that's the cheaper option for a team of one.

I only reach for free-plus-ads now for that low-ceiling category above, where the value per use is genuinely small and the audience is big enough that the ad math works without a growth team behind it.


What I actually do now

Before I build the paywall screen, I write one sentence: this is worth paying for because ___. If the honest answer is "it solves a problem once," that's a one-time price. If it's "it keeps giving you something new," that's a subscription, and one I need to actually mean. If it's "it's minor but a lot of people will use it," that's free with ads, budgeted for the support time it'll cost me.

None of this needed a spreadsheet full of competitor screenshots. It needed an honest answer about what the thing actually is. The pricing model was never really the decision. It's the receipt for a decision about the product I'd already made, whether I noticed it or not.

That's the reality of being a team of one.

#TeamOfOne #BuildInPublic #Pricing #IndieHackers #SoloFounder

← All posts