Who actually pays for my app, and why does it matter?

Your customer is whoever hands you the money, and only those people count when you add up revenue. On a marketplace, a free app funded by someone else or a product sold through an employer or a school, the people who use the product and the people who pay for it are different groups. Name the payer first: your price, your market size and the number of customers you need all hang on that answer.

Users and payers are not the same people

A lot of products built with AI start the same way: something useful, a few hundred people using it, and a vague sense that money will follow. The vague part is usually who it will come from.

For a simple tool, the answer is obvious. The person who signs up is the person who pays. But plenty of projects are not built that way:

• A booking app where students use it and teachers pay for the listing.
• A study tool that students use for free and a school pays for.
• A recipe site that readers use for free and advertisers pay for.

In each case, counting "users" tells you nothing about revenue. It tells you about traffic.

This is not a niche concern for solo founders. In 2024, solo founders started 30% of new startups but raised only 14.7% of the money in priced rounds (Carta, 2025). Most of them are not funded by investors. They are funded by customers, which makes knowing exactly who those customers are a survival question, not a slide in a deck.

Four ways money can reach you

Almost every project fits one of four setups. Pick yours before anything else.

1. Direct sale. The user pays you. A subscription, a one-off purchase, a service. User and payer are the same person.
2. Matching two groups. You connect two sides, like teachers and students or freelancers and clients. One side pays, or both do, often as a commission on what changes hands.
3. Selling to an intermediary. You sell to an organization that gives the product to its people: an employer, a school, an agency, a franchise. The organization pays, its people use it.
4. Free users paid for by a third party. Users pay nothing. Someone else pays to reach them: advertisers, sponsors, partners.

The setup is not a label for the pitch. It decides who you have to convince to get paid, and that is often not the person you designed the product for.

A worked example: one app, counted three ways

Take a booking app for independent yoga teachers. As a hypothesis for the example, it has 3,000 students and 150 teachers using it. The founder plans a price of €25 a month.

The trap: counting everyone as a customer.

3,150 users × €25 = €78,750 a month

That number feels great and means nothing, because students were never going to pay a monthly fee to book a class.

Setup 1, teachers pay a subscription. Only teachers count in money.

150 teachers × €25 = €3,750 a month

The trap overstated revenue by 78,750 ÷ 3,750 = 21 times. Same app, same users, one wrong assumption about who pays.

Setup 2, a commission on each booking. Say students book 2 classes a month on average, at €12 a class, and the app keeps 10%.

3,000 × 2 × €12 = €72,000 booked a month

€72,000 × 10% = €7,200 a month

Better on paper. But now you have to decide who carries that 10%. If it is taken from the teacher's payout, each of the 150 teachers gives up 7,200 ÷ 150 = €48 a month on average, nearly twice the €25 subscription. Teachers are still the payers, they just see it differently. If it is added on top of the student's price, students become the payers, and each class costs them €13.20 instead of €12. Same revenue on paper, a different person to convince.

Setup 3, sell to studios. Suppose 6 studios pay €400 a month to give the app to their teachers and members.

6 × €400 = €2,400 a month

Fewer payers, larger cheques, and a completely different sales job: you now sell to a studio manager, not to a teacher.

None of these is the right answer in general. The point is that each one gives a different revenue figure, a different person to persuade and a different number of customers to win. You cannot compare them, or pick one, until you have said who pays.

Why "I don't know yet" is not an answer

It is tempting to leave the question open and "see what works". The problem is that everything downstream needs it.

• Price. A teacher, a student and a studio do not compare your price against the same thing.
• Market size. You count the payers, not the users. 3,000 students and 150 teachers are two very different markets.
• What you described as the product. If you have already written down what your customer actually buys, check that the buyer in that sentence is the payer, not just the user.
• The model itself. A revenue model is one sentence that starts with "someone pays". If you cannot name the someone, the sentence has no subject.

A founder who cannot say who pays does not have a model yet. That is fine on day one. It is not fine once you start making decisions that assume one.

What this does not cover

Naming the payer does not prove they will pay. That only comes from real people handing over real money.

It does not size your market either. It tells you which group to count, not how many of them exist or where you will sell to them.

And setup 4, free users paid for by a third party, needs more inputs than the others. Advertising revenue depends on your traffic and on what advertisers pay to reach it. You need a credible estimate for both before that setup says anything useful, and without one it is the easiest setup to fool yourself with.

How Banast does it

The first chapter of a Banast report asks how your project works, with four options matching the four setups above: direct sale, matching two groups, selling to an intermediary, or free users paid for by a third party. Then it asks who pays you.

There is deliberately no "I don't know" option. From that point on, only the people who pay are counted in money. A founder who cannot answer does not have a model yet, and the report is built to make that visible rather than calculate around it.