You’ve got the idea. Maybe you’ve already sketched a screen or two. And somewhere on your list is a line that says “figure out the money later,” filed next to the app icon and everything else that can wait.
Money can’t wait. Not because you need a final price this week. You don’t. It’s because how your app earns money decides what you build. Skip this now and you don’t save time, you spend it twice: once building the wrong thing, and again rebuilding the right one.
This isn’t a pricing decision yet, and it isn’t a spreadsheet. It’s one honest question about your own idea, and it takes an afternoon. Answer it before you design a single screen.
Where this sits in the journey
The last few issues told the truth about what already happened. The real bill for building two apps, the price I picked with three questions instead of a spreadsheet, and what real strangers taught me the week they showed up. That was Arc One, the Honest Launch Report.
Arc Two starts today, and it runs the other direction. Make It Pay is six issues on one theme: the money decisions that are cheaper to make on purpose than to discover by accident.
The money decision you make before you build (you are here)
Free, paid, or subscription: how your app should make money
How to design a paywall people don’t resent
The pricing experiment you can run in a week
Trials, refunds, and the churn you can actually prevent
The five numbers to check every Monday
Today’s issue comes first because it comes first in real building, too. Before you design a screen, before an agent writes a line of code, you decide how the app will earn. Everything downstream depends on that answer, so it’s worth getting right while it’s still cheap to change.
Why the earning model comes first
Most first-time founders treat money as a setting they flip on near the end, after the app already works. Add a paywall screen, pick a number, done.
That’s backwards, and it costs you real time. The earning model is a structural decision that shapes the product underneath it, not a setting you bolt on later.
An app built around a subscription needs an account system, a way to track what’s unlocked, and a natural moment in the flow to introduce the paywall. An app built around a one-time purchase needs none of that: no ongoing account state, no renewal logic, nothing to protect after the sale. Design your onboarding and your data model around the wrong one, and you pay for it later. You end up rebuilding the account system, the paywall screen, and the onboarding flow, not adjusting a price, because one decision landed after the build instead of before it.
The four shapes your app’s money can take
Every small app earns money one of four ways. You don’t need to pick one today. Know the shapes first.
Free - no charge to the user, funded by ads or nothing at all. It only works at real scale: thousands of daily users, enough to make an ad network worth the screen space. For a solo founder’s first app, free is usually a distribution choice pretending to be a business model.
One-time purchase - the user pays once and owns it. Clean and honest, and the right shape for something with fixed value: a calculator, a template pack, a reference guide. The tradeoff is growth. Every dollar of revenue needs a new buyer, because nobody pays twice for the same unlock.
Subscription - the user pays monthly or yearly for access that keeps giving them something. The default for apps with ongoing value: habits, learning, tracking, anything the app keeps doing for you over time. Harder to sell on day one, and the only shape that compounds.
Freemium - free to download, some of it free forever, a paid tier that unlocks the rest. The free layer earns trust before you ever ask for a dollar. The paid layer is where the business lives.
The one question that narrows it fast
You don’t need a worksheet to get moving today. You need one honest answer about yourself, not your users, not yet.
Am I willing to keep improving this app for years, or do I want to ship it once and be done?
Say “once and done,” and two of the four fall away on their own. A subscription asks someone to keep paying for something you keep improving. If you’re not planning to keep improving it, that’s not an honest ask, so subscription is out. Freemium leans on the same ongoing relationship, so it goes too. What’s left fits: a one-time purchase, priced fairly, for people who want the thing as it exists today.
Say “years,” and the other two fall away instead. A one-time purchase leaves money on the table for every year you keep working on the app after the sale. Free, without real scale behind it, can’t fund years of your time. What’s left fits: subscription, or freemium as the door into it.
Try it on your own idea right now, in one sentence: “I am willing to keep improving [your app] for [once and done, or years], because [reason]”. Whichever way you land, you’ve ruled out two of the four, honestly, before you’ve opened a design file.
Ocho and Banded both landed on “years.” Not because either app demanded it, but because the goal was a real business, not a single sale. That’s why both launched freemium, with the paid layer as where the business lives. Which exact model fits the two you have left, and the scored worksheet that proves it, is next week’s job. Today you only need the direction, and you already have it.
That one question is enough to start with. Next week: which of the two shapes you still have left actually fits your idea, and the scored worksheet that proves it.
