What Counts as a Pre-Revenue Project
Plenty of builders assume a marketplace only wants finished businesses with a Stripe dashboard to screenshot. That leaves a huge amount of finished work sitting in private repositories, doing nothing. If you have shipped something real but never turned on billing — or turned it on and never got the first customer — you have an asset that another operator would rather buy than rebuild.
Concretely, four kinds of projects fit this page. Each has a genuine buyer, even with a revenue line that reads zero.
The used-but-unbilled tool
A product with real people logging in every week, where you simply never wired up a paywall. Usage is proof of demand.
The finished-but-unlaunched MVP
A build that works end to end in a demo but was never pushed public. The buyer inherits a shortcut to a shippable product.
The waitlist product
Landing page plus a signup list that has been validating an idea. The list itself is a warm launch audience worth money.
The parked build with traffic
Something you drifted away from that still pulls organic visitors or ranks for a keyword. Dormant, but not dead.
Why Someone Pays for a Zero-Revenue Asset
The instinct that a project is worthless without income comes from valuing it like a business — a stream of profit multiplied by some number. A pre-revenue project is not sold that way. It is sold like a component: a chunk of finished work priced against what it would cost the buyer to reproduce it. Once you frame it as build-versus-buy, the money becomes obvious.
Picture a competent developer who wants to launch in the same space you built in. Doing it themselves means roughly three months of nights and weekends: architecting the app, wiring authentication and payments, fixing the edge cases you already fixed, then registering a domain and waiting on it to age. Against that, a working codebase with a clean repository, a domain that already exists, and a running demo is not a gamble — it is a purchase that hands them the head start intact. Paying a few thousand dollars to erase a quarter of unpaid engineering is a rational trade, and many acquirers make it deliberately.
Distribution is the second reason, and it is often the bigger one. Code is reproducible; an audience is not. A waitlist of a few thousand people who raised their hand for exactly this idea, a subreddit-sized community, or a page that quietly ranks on the first results page for a buying-intent search — these are assets a buyer cannot spin up with a weekend of effort. An operator who already knows how to convert attention into revenue will pay real money for a warm audience attached to a product they can charge for immediately. You did the expensive, slow part; they bring the monetization they are already good at.
There is a quieter third factor too: the groundwork that only shows its value later. An indexed domain with a bit of history, a schema that is genuinely thought through, an integration with a hard-to-approve API, or a niche a larger buyer wants a foothold in — none of these produce a dollar today, yet each shortens the buyer's path to their own launch. That is what they are actually paying for: not your past revenue, but their compressed future.
How Pre-Revenue Projects Are Valued
With no revenue to multiply, price is assembled from the parts a buyer would otherwise have to build or acquire. The dominant input is replacement cost — the developer hours already sunk into the project, valued at a plausible hourly rate — with everything else stacked on top: the size and warmth of any audience, the strength of the domain and brand, and how hard the underlying tech is to copy. The table below shows how those inputs combine into the ranges we typically see for pre-revenue listings.
| Valuation input | How to estimate it | What lifts it |
|---|---|---|
| Replacement cost | Developer hours already invested × a realistic hourly rate (a solo builder's 300 hours at $30–$60 is a defensible floor) | Clean, documented code; a modern stack; features that are tedious to rebuild |
| Audience & waitlist | Signups, email subscribers, community members, or active weekly users, weighted by how targeted they are | A niche list that matches the product; engaged users over vanity numbers |
| Domain & brand | Registration age, keyword match, memorability, and any organic traffic the domain already pulls | An aged, brandable, exact-match domain that ranks for buying-intent terms |
| Technical uniqueness | How hard the core would be to reproduce — a novel model, a scraped dataset, a hard-won API approval | Defensible tech a buyer cannot recreate cheaply or quickly |
These inputs land most projects in one of three bands, which is where nearly every pre-revenue listing on ExitBid opens.
| Project profile | Typical range | What it looks like |
|---|---|---|
| Bare MVP | $500 – $5K | A working build with no users and no audience — priced almost purely on replacement cost |
| MVP with users or a waitlist | $2K – $15K | A functioning product plus real traction: active weekly users, a warm signup list, or organic traffic |
| Unique tech or a strong audience | Higher, uncapped | Defensible technology, a sizeable targeted list, or a domain that already ranks — the auction sets the ceiling |
These are opening-price anchors, not appraisals — the final number is whatever bidders decide it is worth. For the underlying method, read our guide on how to value a pre-revenue project, then plug your numbers into the valuation calculator to sanity-check your floor before you list.
Why an Auction Beats a Fixed Price Here
Fixed pricing works when there is a formula everyone agrees on. A profitable SaaS has an MRR figure and a customary multiple, so buyer and seller can argue over a fairly narrow range. A pre-revenue project has neither. Ask ten builders what an unlaunched MVP with a 2,000-person waitlist is worth and you will get ten different answers, because there is no anchor number to divide by. Naming a single sticker price in that fog almost guarantees you are wrong — either you scare off every buyer with an optimistic tag, or you quietly leave money on the table with a conservative one.
An auction removes the guessing from your side of the table. Instead of you predicting the market's number, the market states it. You set the opening bid at the lowest figure you would genuinely accept — your replacement-cost floor — and the five-day auction lets competing buyers reveal the ceiling through their bids. If two people both see a shortcut worth having, their competition surfaces a price that no solo negotiation would have produced. The uncertainty that makes a pre-revenue project awkward to price by hand is precisely the thing a live auction is built to resolve.
The practical upshot: you never have to defend a valuation you invented. Set a floor you are happy to walk away with, and let a room of interested buyers argue the rest upward on your behalf.
What to Prepare for a Pre-Revenue Listing
The paperwork here is different from a revenue-generating sale, and that is fine. Nobody expects a profit-and-loss statement for a project that has never billed a customer — trying to fake one only erodes trust. What buyers want instead is proof that the work is real, transferable, and close to the finish line. Assemble these before you open your listing:
- Repository access and a README — a buyer needs to see that the code exists, builds, and is documented well enough to hand over without you.
- A short demo video — two or three minutes walking through the working product does more than any description. It is the single strongest signal for an unlaunched build.
- Screenshots of any traction — waitlist counts, analytics, traffic graphs, or an app dashboard. Whatever numbers you do have, show them plainly.
- The domain and any brand assets — registrar details, logo, social handles. List exactly what transfers with the sale.
- A monthly running-cost breakdown — hosting, APIs, any subscriptions. Buyers want to know what the project costs to keep alive from day one.
- A brief roadmap — the two or three obvious next steps you would have taken. This helps a buyer picture the upside they are buying into.
Notice what is missing: no revenue history, no churn table, no customer contracts. A pre-revenue listing is judged on the strength of the asset and how ready it is to run, not on a track record it does not have yet. Honesty about the gaps — the launch that never happened, the marketing you never did — reads as credibility, not weakness.