Revenue Model

Build something good and the money follows was received wisdom for a long time. So teams spent months deciding what to build and deferred how to charge for it until later, as though the charging method were something that could be attached at the end like a payment button.

Deferring it gets paid for afterward. A team that opened every feature for free to gather users and then tries to add billing a year later has to start by taking away what was free. At that moment the customer isn't buying a new capability; they're losing one they had, and churn arrives before conversion does. Charging per person has the mirror problem: a product built on that basis stops earning the moment several people at one company share a single account, and that structure is hard to change once the product has shipped.

As cases piled up of the same product recovering after only its charging method changed, this item moved onto the design table. A revenue model is the part of a business structure responsible for money coming in, and it gets handled as a pair with the cost structure that handles money going out.

What a revenue model settles is the method of charging. Three decisions make one model: what carries the price, who pays it, and on what cycle. Four approaches come up most often.

1. Subscription. A fixed amount every cycle. Next month's revenue is predictable, and in exchange the product has to keep producing reasons to renew. It also makes the renewal date the moment that matters, which is why subscription businesses measure retention rather than one-time satisfaction.
2. Usage-based pricing. Charge for what gets consumed. New customers can start with little commitment and heavy customers pay more, but this month's revenue depends on their consumption, which makes forecasting harder. It also turns the sales conversation from a contract size into a forecast of consumption.
3. Transaction fees. Take a percentage when a transaction happens. Mostly used in a two-sided market, which needs both sellers and buyers present to function, and which side pays has to be decided separately. Charging both usually keeps both from showing up, so one side ends up subsidized by the other.
4. Advertising. Charge nothing for use and sell the space on the screen to advertisers. The party paying and the party using come apart, so the product ends up chasing time spent rather than conversion.

Where the free tier ends is decided inside this structure too. Opening the basics for free and charging only for advanced features is freemium, and the boundary of the free tier is where payment happens. Drawing that line is the single decision that most affects how many users ever pay anything.

How much to charge is not settled here. Once the method is subscription, arguing over $7 a seat versus $12 is pricing. Reverse the order and you fix a price first and then look for a method that produces it, and usually none fits.

Using only one is not required. Pagedeck charges $7 per person per month on a team subscription, leaves the first three seats free, and charges usage on storage above a set limit.

In business design it sits next to the cost structure, because the charging method determines the character of the costs. Charging on usage moves revenue and server bills in the same direction, which limits the downside; a flat subscription leaves the amount collected unchanged even when one heavy customer drives costs up sharply.

It is also an input to unit economics, the calculation that compares profit and loss per customer, because the billing cycle sets the payback period. If acquiring one account costs $450 and it pays $7 a month with $1.50 of that going to cost, recovery takes close to nine months. Bill the same customer annually up front and recovery finishes in the first month, which makes the billing cycle a financing decision as much as a pricing one.

It lands on product design as well. What stays free and where the payment screen goes both come out of this structure, so a feature gets assigned to the free or the paid tier as it's built.

The shape of the organization shifts too. A company charging by subscription grows a customer success team that handles renewals; one charging transaction fees puts people on raising transaction volume. Both functions can exist in one company, but the larger one follows the money. Investor material explains this structure first, because without knowing the path money takes, a growth rate doesn't say what it's a growth rate in.

"Moving from per-seat to usage-based makes revenue harder to forecast."

Changing the charging method changes how planning itself works.

"We're deciding the charging method right now; price comes after."

Handle the revenue model and pricing in that order.

"If we go with advertising, user count sets revenue, so the product target becomes time spent."

Change the path money takes and the number the product chases changes with it.

At Pagedeck the conversation reopened because of storage. A handful of teams putting large images and video into documents were spending twenty times more on servers than everyone else, and a per-seat structure left that difference invisible in revenue.

What Grace and Mia chose was not replacing the structure but adding one branch to it. Per-seat subscription stays, a storage limit gets set, and only the overage is charged separately. For most customers the invoice doesn't change, because the limit sits well above what a typical team stores; it rises only at the few accounts driving the cost.

The most common mistake is treating the revenue model and the price as the same decision. Both are about money and both come up in the same meeting, so the line blurs. But the first settles the method of charging and the second sets an amount inside that method. Mix the order and the discussion spins: argue over $7 against $12 before deciding whether to charge per seat or per usage and there is no basis for judging which is right.

The other belief is that it gets decided once. It feels foundational enough to be unchangeable. In practice, moving from per-seat to usage-based or redrawing the free tier boundary happens regularly. It does carry a cost, though. Existing customers' invoices change, so they usually need to stay on old terms for a while, and the billing system, the contracts, and the sales material all have to be revised together. The usual approach is to leave existing customers on the old structure and apply the new one to new customers. So thinking it can't be changed is wrong, and thinking it can be changed lightly is also wrong.