How to Sell a Pre Revenue SaaS Company

The number you are looking for does not exist. Nobody is going to buy a software company with no customers for a multiple of anything, because there is nothing to multiply.

That sounds like bad news and it is not. The price just gets set a different way, and founders who understand that way do better than founders still hunting for a formula.

We know what it is like to build something before it earns revenue. You put a lot of work into it, and you want to find it a good home. That work has value, and the right buyer can see it.

Acquisitions are happening. Carta counted 421 startup exits through M&A in the first half of 2026, the busiest first half they have on record and 16% more than a year earlier.

The dollar figures attached to that market are worth a look before you price anything, because they describe somebody else. Total exit value in the same period topped $2 trillion, and $1.7 trillion of it came from a single company going public. Carta calls the market extraordinarily top heavy. The numbers founders read in headlines are not from the market you are selling into.

By the end of this post you will know what a buyer is actually comparing your company against, the one document to build before you name a price, how to tell whether you should be selling at all yet, and how to find a buyer and close the sale yourself.

Why there is no formula to sell a pre revenue SaaS

It is a reasonable thing to want. Companies with revenue trade in ranges everybody quotes, so it feels like there should be a version of that range for companies without any. A multiple of signups. A multiple of what you spent building it. Something.

Marketplace listings make it worse, because you can see other people’s asking prices sitting right there on a page. An asking price is not a sale price, and the ones that sold are not the ones still listed.

So founders arrive at a number, attach it to a company nobody has paid for yet, and then read every conversation that follows as a negotiation about that number. Most of those conversations end quietly. The reason is that a pre revenue SaaS is not priced against other companies at all.

What the buyer is actually comparing you against

When there is revenue, a buyer weighs your company against other companies they could buy instead. With no revenue that comparison disappears, and a different one takes its place. They compare buying you against building it themselves.

That comparison has a real price on it. The US Bureau of Labor Statistics puts the median software developer wage at $135,980 as of May 2025. Put 2 developers on something for 9 months and you have spent about $204,000 in salary before you add benefits, a manager, or the months of calendar time.

Calendar time is usually the expensive half. A buyer who builds it does not have the thing for 9 months. If a customer is asking for it now, or a competitor ships it next quarter, those 9 months cost more than the salaries do.

That is what you are actually selling. Not what you spent. What they save.

The build sheet

Before you name any price, write the document the buyer builds in their own head anyway. Then you are both reading the same page instead of arguing across 2 different ones.

It has 4 parts.

1. What it would take to rebuild what exists. Number of engineers, number of months, honestly. Not what it took you, which included every wrong turn. What it would take somebody starting today who already knows what to build.
2. What they cannot buy back with salary. This is the part founders undersell and it is usually worth more than the code. Integrations that are already approved by the other side. An app store listing that already cleared review. A security questionnaire you already answered for a company everybody has heard of. 2 years of conversations with users that told you which 3 features actually matter. None of that arrives faster because you hired more engineers.
3. What is broken or missing. Write it down yourself. Every buyer finds it anyway, and finding it after you claimed the thing was clean costs you more than disclosing it costs you.
4. Proof that somebody wants it. Without revenue this is the hardest part to evidence and the easiest to fake, so buyers discount anything soft. Signups and waitlist numbers count for almost nothing. A signed pilot counts. A paid pilot counts for much more. A letter of intent from a named company counts. A distribution partner who has already integrated you counts. Write down what you have, with dates and names you can back up, and leave out everything you cannot.

The build sheet does something a price cannot. It moves the conversation from what you think it is worth to what it would cost them to not have it.

Almost every deal like this is an asset sale

The structure catches people at the end, when it is too late to change.

In an asset sale the buyer picks which assets and liabilities they take, and the company that sold them typically pays off whatever is left and shuts down. They are not buying your company. They are buying a list, and your company dissolves behind it.

That has 2 consequences worth planning for.

Anything not on the list does not transfer. The domain, the repository, the app store account, the analytics, the design files, the cloud accounts, the customer email list. If any of it sits in a personal account or an old contractor’s login, it is not yours to sell, and that surfaces in the week everybody wants to close.

And every contributor has to have signed their work over to the company. A contractor who wrote a module in 2024 and never signed anything still owns that module. This is the same chain of title cleanup a company with revenue does, except you have less room to argue, because the code is most of what is being sold.

The 4 routes, and which one fits

Founders assume there is 1 exit and it either happens or it does not. There are 4, and the honest answer usually picks itself.

The 2 routes founders skip are worth naming plainly. An acquihire is a real outcome, but the product usually dies and the money follows the people, so a solo founder has less to sell than a team of 4. A marketplace listing suits a product that genuinely runs without you and suits nothing that needs explaining, because those buyers are individuals purchasing an operating asset rather than companies buying time.

Where the doubters are right

The argument against selling now deserves a straight answer.

Revenue changes the category you are sold in, not just the price. Even modest recurring revenue puts you back among comparable companies, brings in the financial buyers who only look at cash flow, and turns a single buyer conversation into a process with competing offers. That is a better negotiation.

So if you can reach real revenue, wait. Real means paying customers who renewed once, not signups and not a pilot that never converted.

Sell now if the honest answer is that you are not going to get there. If the money ran out, if the co founder left, if the market moved, or if you simply do not want to spend 3 more years on it, then the build sheet is the tool and a strategic buyer is the buyer. That is not a failure. It is a different transaction with different mechanics, and the revenue playbook mostly does not apply to it.

How to sell a pre revenue SaaS yourself, step by step

You do not need a broker or an adviser to sell a product with no revenue. You need a clear package, a short list of the right companies, and a steady way to reach them. Here are the 8 steps, in order.

Step 1: Know what you are selling and what it is worth

Write a list of everything a buyer would get. Most products have 6 parts: the code, the intellectual property, the domain, the users, the data and the team. Intellectual property means the things you own on paper, such as the code, the brand name, the designs and any patents.

Not every buyer wants every part. Some buyers want the code and nothing else. Some want the team and plan to shut the product down. Mark which parts you are willing to sell on their own.

Then set a price range with the build sheet from earlier in this post. The top of the range is what the buyer saves by not building the product: the cost of the engineers, the months they would lose, and the things more engineers cannot speed up, such as integrations a partner already approved and real users. A buyer pays a share of that saving, not all of it. There is no standard share. It goes up when the buyer needs the product soon, and when a second buyer is interested.

The bottom of the range is the least you would accept. One way to set it is to ask what the product is worth to you if you keep it, or what you need to pay off its costs and debts. Write both numbers down before you talk to anyone. When a buyer asks for your price, you can show how you got it.

Step 2: Package it

A buyer decides in a few minutes whether to look closer. Make that easy with 5 things:

• A summary on 1 page. What the product does, who it is for, and why a company would want it now.
• A short demo video. 3 to 5 minutes, recorded on your screen, showing the main task from start to finish.
• The tech stack. The languages, tools and hosting the product runs on. A buyer’s engineers check this first, to see whether it fits what they already use.
• Users and proof of demand. Signups, active users, pilots and partners, with dates. A pilot is a trial run of your product inside a real company. List only what you can prove with a screenshot, an analytics export or a signed document.
• What transfers to the buyer. The list from Step 1, plus every account the product runs on: the domain, the code repository, the app store account, the cloud accounts and the design files. The asset sale section earlier in this post explains why each one must be in the company’s name.

Keep the package to what a busy person can read in 10 minutes. Send the full detail later, to the buyers who ask for it.

Step 3: Build a short list of buyers

The best buyers are companies that would use your product right away. Look in 4 places:

• Companies your product extends. If your tool adds a feature to a larger product, the company behind that product is the first name on your list.
• Competitors. A competitor may buy your product to get your users, your features or your integrations.
• Companies in a related market. They sell to the same customers, but they do not offer what you built yet.
• Teams that could hire you. Some companies want the people more than the product. They may hire you and buy the product as part of the same deal.

For each company, write 1 sentence on why it would want your product now. If you cannot write that sentence, take the company off the list. A short list with a clear reason next to each name gets more replies than a long list of guesses.

Step 4: Find the right person at each company

Your message needs to reach a person who can decide to buy. Who that is depends on the size of the company:

• Large companies: the corporate development team. This is the group whose job is to find and buy other companies.
• Smaller companies: the founder or the CEO. At a small company, they often make this decision alone.
• Any size: the head of product. This person knows whether your product fills a gap in their plans, and can take it to the people who decide.

Write down 1 name for each company, and a second name in case the first person does not answer.

Step 5: Use simple tools to find names and email addresses

You have several options. Use the ones you already know:

• A contact lookup service. Apollo is one example, and others do the same job. You search by company and job title, and the service shows names and work email addresses.
• LinkedIn. Search for the company, filter its people by job title, and send a direct message or a connection request with a short note.
• The company’s own website. Team pages, press pages and press releases often name the people in charge of products and partnerships.

Step 6: Reach out, then follow up

Your first message has 1 job: to get a reply. Keep it short, say why you picked this company, and ask 1 easy question.

Most people do not answer the first message. That is normal, and it is why the next messages matter. Send 3 to 4 more over the next 2 to 3 weeks:

1. Day 3 or 4: a short reminder of your first email, with the demo link.
2. Day 7 to 10: 1 new fact, such as a new user, a new integration or a short clip of a feature they would care about.
3. Day 14: ask whether someone else at the company is the better person to talk to.
4. Day 18 to 21: a polite last note. Say you will not write again, and that they can reach you any time.

Track every company, name, date and reply in 1 simple sheet. When 2 or more buyers are interested at the same time, tell each of them, in plain words. For example: “Another company has asked for a demo, so I plan to decide in the next 2 weeks.” Interest from a second buyer is often what gets the first one to make an offer.

Step 7: Protect yourself

Buyers will want to see your code and your user data before they pay. Let them, in this order:

• Sign a simple NDA first. An NDA, or nondisclosure agreement, is a short contract in which the buyer promises not to share or use what you show them. Sign one before you share code, user data or anything you would not post in public. Many buyers send their own. A lawyer can give you a standard one, or check theirs before you sign.
• Do not hand over the source code until there is a signed letter of intent. A letter of intent is a short document in which the buyer sets out the price, how and when you get paid, and what it gets, before the final contract. The buyer usually writes it. Until then, show the product only in demos and screen shares.
• Use escrow for the payment. In escrow, a neutral company holds the buyer’s money. It pays you once the code, the domain and the accounts have moved to the buyer, so neither side has to trust the other to go first. Escrow.com is one example of an online escrow service. These services charge a fee, so agree in the letter of intent on who pays it.

Step 8: Sign an asset purchase agreement

The final contract for an asset sale is called an asset purchase agreement. It lists every asset the buyer gets, the price, when and how you get paid, and the promises you make about the product. Examples: that you own all of the code, that the product does not copy anyone else’s code, and that the user numbers you showed are true. If one of those promises turns out to be wrong, the buyer can ask for money back. So read every promise closely.

Have a lawyer review the agreement before you sign. Pick one who works on small company sales and on software. Founders who sold a company can often name one, and most state bar associations run a lawyer referral service. Ask for a fixed fee if you can. Also talk to a tax adviser before you sign, because the way the price is split across the assets changes the tax you pay.

After you sign, move everything on your Step 2 list to the buyer, including the passwords. The domain registrar, the app store and the code host each have their own transfer steps, and some take a few days, so start them the same day. The escrow company releases your money once the buyer confirms it has everything. In an asset sale your company still exists afterward, with nothing left in it. Ask your accountant how to close it down.

Frequently asked questions