Plugging In the Business Model
The product definition has to answer where the money comes from, or it stalls after launch.
When the product definition is written, one sentence is still missing: why this thing deserves to keep existing. Without an answer, what you build can only sit on your own machine.
What you'll run into:
- The product is finished before you start thinking about charging, and there's no clean place to add it
- You add a paywall and users leave instantly, because the free version already did the job
- You want a subscription, but users touch it once a month and there's no honest renewal pitch
A common thought: "build a great product first, and once there are enough users we'll figure out how to make money." That holds under one condition—you can survive until the users show up. Solo, you usually can't. So decide how you charge during the definition phase, not after launch: one afternoon spent on where the money comes from saves a whole rework cycle of "built it and nobody pays."
How it reshapes the product
The same note-taking product, under different ways of charging, becomes different products.
| Charging model | What the product must prove | What the structure grows |
|---|---|---|
| Subscription | I'm still helping you this month | Weekly reports, usage stats, ongoing content. The homepage must show accumulated value at a glance |
| One-time purchase | This alone is worth the price | Feature completeness is the selling point; no need to retain. "Done and gone" works |
| Advertising | Lots of people stay here a long time | Feeds, recommendations, infinite scroll—in direct conflict with helping users finish quickly |
| Usage-based | The more you use it, the more you get | Usage must be visible, with quota reminders. Most AI products go this way |
The third row is the most typical value conflict. In an ad-funded product, the PM's KPIs and the user's interests point in opposite directions. No design technique resolves that contradiction—the only fix is not choosing it in the first place.
How to pick among the four? Go back to your product's shape: if users engage weekly and value accumulates over time, subscription fits. For one-shot tasks that users finish and leave, a one-time purchase is more honest. For low-frequency, high-value-per-use situations, usage-based or per-use pricing flows most naturally. AI products mostly combine subscription with usage-based pricing because both demand "more usage"—which is directly tied to whether your core action is frequent.
The free / paid line
If you're running a freemium model, where this line sits is life or death—and the two ways to get it wrong are exactly opposite.
- The free version is too good. Free: unlimited entries, all core features. Paid: themes and PDF export. The job is already done, so nobody has a reason to pay.
- The free version is too painful. Free: three items, locks everywhere. Paid: normal use. Users are stopped before they ever feel the value, and they walk.
- When the line is right. The free version can complete one task end to end; paying buys volume, collaboration, or saved time. Say, free lets you organize one project, while paying lets you manage ten with automatic archiving.
The test: free users should be able to recommend you sincerely, and paid users should feel the money was cheaper than the time it saved. When both hold, the line is right. This is the core difficulty of freemium—too generous and nobody buys, too stingy and nobody comes. freemium-wiki
The line isn't fixed forever either. Early on, give the free tier more to earn feedback and word of mouth; tighten it once the product stabilizes. Watch the same pair of metrics on every adjustment: the free-to-paid conversion rate and paid-user retention. If only one moves, the line is still leaning one way.
A final check. Read "who we help with what" and "how we charge" side by side in your definition. If the charging model reads as unrelated to the core value, it hasn't actually connected—either redraw the line or go back and rewrite the definition.