How to value an app: what is your app worth?

Why valuing a small app is hard

Houses and cars have comparable sales. Small apps mostly do not. Two apps with the same monthly revenue can be worth very different amounts if one is stable and easy to hand over and the other depends on its founder and one traffic source. So nobody can hand you a number, and you should be wary of anyone who tries.

What you can do is understand what a buyer is really purchasing, weigh the factors honestly, and arrive at a range with a floor and an asking price. Think of value as the price at which a particular buyer, with full information, would say yes. A listing price is an opening position, not a verdict. This guide does not quote multiples or market statistics, because your own evidence is better.

Start with what the buyer actually gets

A buyer is paying for some mix of these things. Be clear about which ones your app really offers:

• Income: money the app earns today and how likely it is to keep earning
• Users: people who already use it, and how they found it
• Time saved: the work it would take to build something equivalent from scratch
• Assets: the domain, the brand, the content and the code
• Audience: an email list or following that comes with the app
• Opportunity: a clear next step the buyer can take that you did not

The factors that move the price

Buyers do not weigh these identically, but almost every serious buyer looks at all of them. Use the table as a checklist for your own app, and be as hard on it as a buyer would be.

Revenue: amount, stability and proof

Revenue is the first thing a buyer asks about, and the least forgiving to exaggerate. Quote the period you mean, such as the last three or six months, rather than your best month. Separate recurring income from one off sales. Say whether a few customers account for most of it, because losing one of them would change the picture.

Revenue on the board is self-reported, so buyers will ask for proof: an export from your payment dashboard, bank records or read access to the dashboard itself. Be ready to show it. Income you cannot evidence is, in practice, worth less than income you can.

Growth, churn and age

A buyer is buying the future, and the past is only evidence. Growth that you can explain, such as a feature launch or a search ranking you earned, is worth more than growth you cannot. Decline that you can explain, such as you stopped marketing six months ago, can also be good news, because a buyer may see an easy fix.

Churn tells a buyer whether people value the app. If customers stay for a long time, income is more dependable. If they leave quickly, the app needs constant new sign ups just to stand still. Age matters because time exposes problems, and a longer track record is easier to judge.

Traffic sources and audience

Where visitors come from can matter as much as how many there are. Traffic that arrives from search, direct visits, referrals and an email list you own is durable. Traffic that depends on a single social post, one platform's algorithm or paid ads that you stop paying for is fragile, and a buyer will price in that fragility.

If the app comes with a way to reach its audience, such as a newsletter, a community or customer contact details you are allowed to hand over, say so. An audience a buyer can reach is an asset in its own right. Check that you are allowed to transfer it.

Cost to run and what is left over

List every monthly cost: domain, hosting, database, email, tools, support and, for AI apps, model usage. Some costs scale with users, and that matters. An app whose model bill grows faster than its revenue becomes less attractive as it succeeds.

Costs also include your time. If the app takes ten hours a week to keep alive, a buyer has to value those hours. An app that runs mostly on its own is worth more than one that needs constant attention.

Founder dependence, code quality and transferability

Ask yourself what would happen if you disappeared for a month. If the answer is that the app would keep running, a buyer sees low risk. If the answer is that support would pile up, deployments would fail and customers would leave, then part of what the buyer is paying for is you, and you cannot be handed over.

Reduce that dependence before you list. Write down how things are done, automate the repeated tasks, and tidy the repository. Code quality matters mainly because it determines how safely a buyer can change the app. Transferability matters because a part that cannot move cannot be sold. A custom domain, exportable code and accounts that can change owners all raise confidence. A project stuck inside one platform or one personal account lowers it.

Pricing an app with no revenue

A no revenue app is priced on what it saves and what it could become. Ask what it would cost to build the same thing from scratch, including the time to design it, test it and get it live. Ask whether the domain is strong, the design is good, the users are real and the idea is validated by use. Then be realistic about the risk, because nothing proves the app can earn.

How to build an asking price

Work through these steps in order. Each one produces a number or a note you can defend.

1. Gather evidence: revenue and cost records, traffic and signup history, churn, and a list of everything included.
2. Estimate the rebuild cost: the hours it would take a competent builder to recreate the app, times a rate you could defend. This is a reference point, not a price.
3. Estimate what the app earns a buyer: revenue minus every running cost, over the period a buyer would care about. For a no revenue app this step is zero, and the rebuild cost and assets carry the price.
4. Adjust for the factors: move your thinking up or down for stability, growth, churn, traffic quality, founder dependence, code quality and transferability.
5. Set a floor: the lowest price you would accept, thinking about what else you would do with the app.
6. Set an asking price above the floor, leaving room to negotiate.
7. Test it. List the app, read the messages you get and adjust. Few messages can mean the price or the description is off. Many messages with lowball offers can mean the same thing in the other direction.

A worked example (an illustration with made up numbers)

The numbers below are hypothetical, round and invented for this example. They are not benchmarks and they are not a recommendation for any real app. The point is to show the thinking, not the answer.

Imagine a small AI tool, 14 months old, on its own domain, built by one person. It has about 40 paying customers, brings in roughly $600 a month, and costs about $150 a month to run, so about $450 is left each month. Revenue has been flat for six months because the founder stopped marketing. Most visitors arrive from search. The founder spends about three hours a week on it. The repository is tidy, and the app runs on a hosting account and a database that can both be transferred.

Now apply judgement. Revenue is modest but steady, which helps. Flat growth with an obvious cause helps a buyer who can market. Search traffic is durable. Low founder time and a transferable stack lower the risk. A small customer base means one customer leaving would be noticed. The rebuild cost and a year of leftover income give two reference points, and neither is the answer.

In this illustration the founder decides the lowest price they would take is $5,000 and publishes an asking price of $7,500, then explains the gap in the listing: steady customers, search traffic, a clean repository and a clear marketing opportunity. Another founder with the same numbers could reasonably choose differently. What matters is that each figure has a reason, and that the founder can show the evidence behind it.

How to price a swap

A swap is two valuations at once. Value both apps on the same basis, using the same factors as above: income, users, costs, effort and handover difficulty. Then ask how much work each app needs from its next owner, because an app that needs a lot of attention is worth less to someone who does not have the time.

If the two values are not close, balance the trade instead of pretending they are equal. Common ways to do that:

• A cash top up from the side receiving the more valuable app
• A defined period of support or training after the swap
• Adding another asset, such as a domain, a code library or an audience
• A staged handover that depends on results

Write down exactly what each person gives and gets, and agree it before anything moves. You can describe what you would accept in your listing by choosing the Swap type, and the swap apps page explains how swaps work on the board.

Common valuation mistakes

• Pricing on the hours you spent building. A buyer pays for what the app gives them, not for your effort.
• Quoting revenue instead of profit, and ignoring model, hosting and support costs.
• Using someone else's asking price as proof of value. An asking price is a hope, not a sale.
• Quoting your best month instead of a typical period.
• Claiming numbers you cannot show.
• Refusing to adjust the price when the market gives you feedback.

When you are ready, put the app on the apps for sale board, see how others describe theirs, and follow the selling guide to list yours.

Frequently asked questions