Side Project for Sale: How Buyers Value Pre-Revenue and Tiny-MRR Projects

A side project with no revenue is not worthless. A side project with $50 MRR is not a business. Most sellers get one of those two wrong, and price it like a hobby or like a startup.

Buyers do neither. They price what they would save by not building it themselves, and what they believe it could earn with more time and attention than you gave it.

Here is how buyers actually value a pre-revenue or tiny-MRR side project, and how to price yours so it sells. This is the version I would hand a friend before they post it for sale.

What a buyer is really paying for

At this size, a buyer is not buying cash flow. A few hundred dollars a month does not pay for anyone's time. They are buying a head start.

• Time saved. Working code, a design, a domain and a launch already done.
• Proof of demand. Signups, users or a handful of paying customers that show someone wants it.
• Distribution. Traffic, rankings, an audience or a list that would take months to build.
• A lower-risk bet. Starting from something live beats starting from a blank repo.

You can see it in asking prices. On StartExus on October 27, 2026, SaaS listings showing no monthly revenue had a median ask of $4,000. Those showing $1 to $499 a month: $5,000. The first few hundred dollars of MRR barely moved the price.

1. Start from replacement cost, not revenue

For a pre-revenue project, the honest question is: what would it cost me to rebuild this? Then a buyer discounts it, because rebuilding is optional.

• Hours, not lines of code. A buyer estimates how long a competent developer would need to reach the same point.
• The hard part. Generic boilerplate is worth little. A tricky integration, a custom pipeline or a polished design is worth more.
• The discount. Expect a buyer to pay a fraction of rebuild cost, not all of it. They are taking the risk that it never earns.

2. Show the code is worth taking over

Code only has value if someone else can run it. Buyers check that quickly.

• A modern, common stack. Easier to hire for, easier to maintain.
• It runs from the docs. A README that gets a new owner from clone to deploy.
• Few personal dependencies. Accounts, API keys and services that can move to the buyer.
• Running costs written down. Hosting, APIs and tools per month. For AI products, model costs per user matter a lot.

3. Traffic and distribution can outweigh revenue

A project with steady organic traffic can be worth more than one with slightly higher MRR. Distribution is the hardest thing to build.

• Organic search. Rankings and clicks that keep coming without ad spend.
• Domain and backlinks. A clean domain history with real links.
• Owned audience. An email list, community or social following that transfers with the sale.

A live example: WTFood, a macro-tracking SaaS listed on StartExus, asks $9,000 on $157 of verified MRR and 12.8K verified visitors a month. The traffic is a big part of that price.

4. Treat users as evidence, not as a number

"2,000 users" means little on its own. Buyers want to know what those users do.

• Active, not registered. Weekly or monthly active users beat total signups.
• Retention. Do people come back after the first week?
• Where they came from. Organic and word of mouth beat a single launch spike.
• Any willingness to pay. Even a few paying users or a waitlist shows the problem is real.

5. With tiny MRR, proof beats the multiple

Once there is revenue, sellers reach for an MRR multiple. At $50 or $200 a month, the multiple matters less than whether the number is real and moving.

• Verified, not screenshotted. Stripe or the payment provider, checked, beats a cropped dashboard.
• The trend. Three months of growth from $40 to $150 says more than a flat $200.
• Churn. Are the same customers still paying?
• Profit after costs. $200 MRR with $120 in API bills is $80, not $200.

Another live example: Shipclip, a bundle of three AI micro-SaaS products, asks $2,500 on $240 of verified MRR and $2,400 of verified profit over 12 months. About 1x yearly profit. Cheap, with proof attached.

Worked example: Say your project makes $150 MRR and costs $30 a month to run. That is $1,440 a year in profit. For example, at 2x to 3x yearly profit, a buyer might pay $2,900 to $4,300. Strong organic traffic or clear growth can push that up. Unverified numbers or heavy upkeep push it down.

6. Make the handover cheap

Buyers price in what it takes to own it. Lower that cost and the price goes up.

• Hours a week. Be honest. A project that needs 2 hours a week is easier to buy than one that needs 15.
• What is included. Domain, code, accounts, users, content, social handles. List it.
• Transition help. A few weeks of answering questions is cheap for you and valuable to them.
• A clear reason for selling. No time, new job, other priorities. Buyers relax when it is believable.

Common pricing mistakes

1. Pricing on hours you spent, not what a buyer saves.
2. Applying a big-company MRR multiple to $80 a month.
3. Quoting total signups with no activity data.
4. Leaving out API, hosting and tool costs.
5. Hiding that the project needs you to run it.
6. Asking a buyer to trust screenshots instead of verification.

Test question: If a buyer rebuilt this from scratch, what would they miss? If the answer is traffic, users or a hard technical piece, price on that. If the answer is nothing, price low and sell fast.

The bottom line

Pre-revenue and tiny-MRR projects sell on a head start, not on cash flow. Price on what a buyer saves and what you can prove.

Keep it simple. Show the costs, verify the numbers, document the handover and set an ask a buyer can say yes to.

To sanity-check a number, try the StartExus valuation calculator, and read the StartExus seller guide before you list.

Browse current SaaS businesses for sale on StartExus, or list your side project for sale for free. No listing fee, no success fee, no buyer fee.