How to Sell Your Software When You Built It Yourself

You built something that works. Maybe it took a weekend, maybe a year. Now you are looking at a live product, an empty dashboard, and a question nobody taught you to answer: how do I actually sell this?

The short answer is that selling software is a sequence, not a talent. You choose who to sell to, you find them one at a time, you talk about their problem, and you listen for the reason they say no. Everything else, from pricing pages to outbound tools, is a way of doing that sequence faster once you know it works.

How do I sell my software if I have never sold anything?

Selling software is the work of getting a specific person to agree that your product solves a problem they already have, and that it is worth paying for. Notice what that definition leaves out: persuasion tricks, a big audience, a sales title. Builders are usually better at the core of it than they think, because they understand the product better than anyone.

What builders tend to lack is not skill but sequence. They launch to everyone at once, hear nothing, and conclude the product is the problem. Usually the product was never shown to the right ten people. If that sounds familiar, the pattern is described in i built it but nobody uses it, and it is far more common than a bad product.

Step one: choose one buyer, not a market

A market is "small businesses" or "developers". A buyer is "the person who runs operations at a 15-person agency and rebuilds the same client report every Monday". You can find the second one. You cannot find the first.

The three-question filter

• Does this person feel the problem weekly? Monthly problems get postponed. Weekly ones get budget.
• Can this person pay without asking anyone? Solo founders, freelancers and small team leads can. Enterprise employees usually cannot.
• Can you find twenty of them by name in an afternoon? If not, the description is still too vague.

If you are unsure who fits, who is my customer walks through narrowing it down from what you already know about your early users.

It feels like narrowing will cost you customers. In practice it does the opposite. A message written for one kind of person reads as if it was written for them, and they reply. A message written for everyone reads like an advert, and nobody does. You can widen later, once the first segment is buying and you know why.

If you have a handful of existing users, start there. Look at who signed up without being asked, who uses the product most, and who complained when something broke. The overlap between those three groups is usually your first buyer, even if it is not the buyer you imagined when you started building.

Step two: write the one sentence

Before you contact anyone, write one sentence that names the buyer, the problem and the result, in the buyer's words rather than yours. Engineers tend to describe the mechanism ("a Postgres-backed scheduler with webhooks") when the buyer only cares about the outcome ("stop missing client deadlines").

A useful test: read the sentence to someone outside tech. If they can repeat back who it is for and why they would want it, the sentence is ready. There is a longer method in how to explain what you built.

Step three: find twenty people by name

Twenty is a deliberately small number. It is enough to see patterns and small enough that you will actually do it properly. Good sources, roughly in order of how warm they are:

The point of the table is order, not choice. Start at the top. Most builders skip straight to cold outreach because it feels scalable, then burn their best prospects with an untested message.

How to find people who already have the problem

The fastest route to warm prospects is to search for people describing your problem in their own words. Look in GitHub issues on tools you replace, in threads titled "alternative to" a competitor, in one-star reviews of the incumbent, and in community posts that start with "is there a tool that". Each of those is a person who has already admitted, in public, that the problem is real for them.

Write each person into a simple sheet: name, where you found them, the exact words they used, and the date. The words matter more than the contact details. They tell you what to say, and they let you open the conversation with something specific instead of a generic introduction.

Step four: have the conversation, not the demo

Your first message should ask about the problem, not pitch the product. Something like: "Saw you mention rebuilding client reports every week. How are you handling it right now?" People answer questions about their own work. They ignore pitches.

What to listen for

1. How they solve it today, and what it costs them in time or money.
2. Whether they have tried to fix it before, and why that failed.
3. Who else is involved in deciding.
4. The exact words they use, which become your website copy.

When it is time to show the product, keep it to the one workflow that solves what they just told you. A tour of every feature tells them you were not listening. For the call itself, what to say on a sales call has a structure that works for people who hate selling.

A first message that gets replies

Hi Sam, saw your post about rebuilding client reports every Monday. I am building something for exactly that and talking to a few people who deal with it. How are you handling it right now?

Three lines. It shows you read what they wrote, it is honest about why you are writing, and it ends with a question they can answer in one sentence. There is no link, no feature list and no request for a call. Those come after they reply. If writing to strangers is new to you, cold email for developers covers the mechanics without the sales jargon.

Step five: price it and ask

Builders often wait until the product feels finished before asking for money. That wait is expensive, because a yes with a payment attached tells you something a free signup never will. Pick a price that a buyer can approve alone, say it plainly, and ask whether they want to start. How to price what you built covers the reasoning if you are stuck between numbers.

Then follow up. Most first sales do not happen on the first message or the first call. A short, useful follow-up a few days later is normal, not pushy.

Expect objections, and treat them as data rather than rejection. The common ones are "not right now", "too expensive", "we already use X" and "I need to check with someone". Write each one down with the person's exact words. When the same objection shows up three times, it is no longer about that person. It is something your sentence, your price or your product needs to answer before the next conversation.

Where this advice is wrong

This sequence assumes a product someone pays for and a buyer you can reach individually. It fits poorly in three cases.

• Consumer apps with a low price. Talking to twenty people one by one does not pay back at $3 a month. You still need the conversations for learning, but distribution comes from content, communities and app stores, not one-to-one selling.
• Products that need a network to be useful. Marketplaces and social tools have to solve a chicken-and-egg problem first, which is a different playbook.
• Enterprise software. Long procurement cycles, security reviews and multiple approvers mean the steps here are only the first meeting of a much longer process.

It is also slow. Twenty conversations take a few weeks if you have a day job. That is the trade: slow and informative now, instead of fast and silent.

When to stop doing it by hand

Manual selling has a natural end. Once you have heard the same objection several times and fixed the pitch for it, and a stranger can read your sentence and reply, the work becomes repetition: finding more of the same people, writing to each, following up, booking the call. That repetition is what tools and agents are for.

This is the part Operater is built to take over for builders: an AI sales agent that finds people who match the buyer you have defined, writes to each one personally, handles the replies and books the conversation. It is in closed beta, and it works best when you already know your buyer and your sentence, which is exactly what the steps above produce. If you are weighing whether to hire or automate at that stage, AI SDR for solo founders compares the options honestly.