How to monetise your app with no users

Monetisation requires someone to pay. Validate willingness to pay before you have users, acquire paying users before you have a polished product, and structure first revenue as direct sales.

Why "build it and they will pay" fails

Most indie builders make the same sequence of mistakes: build the full product, set up a Stripe integration, launch publicly, and wait for sign-ups that convert to paying users. The funnel never fills. The product gets iterated. The builder eventually questions whether the idea was wrong.

Usually the idea is fine. The sequence is wrong. Monetisation does not start at launch — it starts at validation. The builders who get to first revenue fastest are the ones who asked people to pay before the product was ready, and used that commitment to fund and shape what they built.

Validate willingness to pay before you have users

The most important signal in early-stage products is not usage — it is payment intent. Someone who says "I would use this" is giving you weak data. Someone who says "I would pay €X for this" is giving you useful data. Someone who actually pays before the product exists is giving you the only data that matters.

To test this: describe the problem your app solves, not the app itself. Ask people if they currently pay for anything to manage that problem. Ask what they would pay for a solution that worked. If you get consistent, specific answers from people who have the problem, you have signal.

If you cannot find five people willing to pay for the solution before it exists, you have a distribution or positioning problem — or the problem is not painful enough to pay to solve.

Pre-sales and waitlists

A pre-sale is a commitment to pay in exchange for early access. You do not need a working product — you need a clear description of the outcome, a price, and a way to collect payment (Stripe, Gumroad, a bank transfer). Sell ten to twenty spots at a discounted early-access price. Use the money and the feedback to build.

A waitlist without a payment commitment is weaker — it measures interest, not intent. Add a small payment at waitlist sign-up (even €5–€10) to filter signal from noise.

Direct sales to individuals

With no users and no inbound, the only reliable path to revenue is outbound: finding individual people who have the problem and selling to them directly, one at a time.

This is not scalable. That is fine. At zero users, the goal is not scale — it is validation and first revenue. Find twenty people who have the problem your app solves. Reach out individually. Show them what you have built. Ask if it solves their problem. If it does, ask if they will pay for it.

This process is uncomfortable, slow, and essential. The builders who get through it fastest are the ones who do not wait until the product is "ready enough to show."

Pricing at zero users

Do not underprice to attract early adopters. Underpricing signals low confidence and attracts users who will demand the most and pay the least.

At zero users, price based on the value of the outcome to the user — not the cost of building the product. If your app saves someone €500/month in other tools or two hours of work per week, charge accordingly. A €20/month price for a tool that saves €500/month is not aggressive. It is cheap.

Typical SaaS pricing for indie tools: €10–€50/month for individual users, €50–€200/month for small teams, higher for specialist or professional tools. Start where you feel slightly uncomfortable. You can always go lower — you cannot easily go higher after establishing a low anchor.

Alternative monetisation for early-stage apps

Paid beta access. Charge a flat fee (€50–€200 one-time) for access to the beta. Frames early access as a privilege, not a workaround for an unfinished product. Attracts users who are motivated to engage seriously.

Done-for-you service. Sell the outcome manually while the tool is still being built. If your app automates a process, offer to do that process manually for the first clients. Charge for the outcome. Use the engagements to learn what the product needs to do. This is how many successful SaaS companies started.

Consulting paired with the tool. Especially relevant for professional or B2B tools. Sell a consulting engagement that uses the tool as infrastructure. Revenue comes from the consulting; the tool becomes a differentiator and eventually the core product.

The sequence that works

Find ten people who have the problem.
Describe the solution. Ask if they would pay for it.
If yes, take a payment — pre-sale, early access, manual service, whatever fits.
Deliver the outcome (with or without the polished product).
Document the result. Use it as a case study.
Repeat with the next ten people.

After fifty paying users, you have enough signal, revenue, and feedback to build the distribution engine. Before that, the engine does not run on its own.

Frequently asked questions

Should I offer a free plan? No, not at zero users. Free users give you usage data, not revenue data. You need revenue data first. Add a free plan later, once you have paying users to compare against.

How do I collect payment before the product is built? Stripe payment links, Gumroad, Lemon Squeezy, or even a bank transfer with a written agreement. Do not over-engineer this. The goal is a commitment, not a polished checkout experience.

What if no one pays? Go back and ask why. Common answers: the problem is not painful enough, the price is too high, the description does not match the user's mental model of the problem, or you are talking to the wrong people. Each answer is useful. Iterate on the positioning before iterating on the product.