Selling SaaS to developers: how to find paying customers

If you spend enough time around indie developers, you hear a familiar piece of advice: stop selling to other builders and sell to businesses with real budgets.

I understand the frustration behind it. You show someone a product, they tell you how they’d build it, suggest six features, and ask whether there’s a lifetime deal. A business owner with an expensive problem sounds like a much better customer.

Sometimes they are. But “builders” and “businesses” are broad groups, and I’d rather know what happens to the buyer if they leave the problem unsolved.

Developers are the people I sell to

My whole business is selling to people who could build things themselves. I sell programming courses, the AI Coding Bootcamp I’ve run every year since 2020, and apps for $20 each, paid once, with the full source code included.

Any buyer of one of those apps could have written it with a coding agent, and the free courses and handbooks on this site sit right next to the paid ones. So “they could do it themselves” can’t be the whole story.

Being able to build something isn’t wanting to

A developer can build a deployment tool, an error dashboard, or an internal database browser, and that work still might not deserve a place in their week. Developers have deadlines too, and systems they’d rather stop thinking about.

Imagine a small team preparing a customer launch with an unreliable deployment process. They can spend a few days improving it, or buy a service that meets their needs and get back to the launch. That’s a different buying situation from a developer casually browsing tools on a Sunday, even with identical skills, because the cost of delay is different.

So I don’t find “they could code it themselves” very predictive. The question is what they’d have to postpone to do it, and whether your product really removes that work. A tool that needs days of setup can lose the comparison with an impressive feature list.

Enthusiasm can look like demand

People who enjoy building are generous with attention. They try new tools, discuss implementation choices, and give detailed feedback, and if you also enjoy building, those conversations feel encouraging. They tell you people are interested, and nothing about whether they’ll pay.

Someone might love your command-line tool as a technical idea and have no recurring need for it. Someone else might use the free version every day and have no reason to buy the paid features. Neither one tricked you, they’re responding to the offer you made.

Trouble starts when you treat praise as evidence for a different offer. “This is cool” isn’t “my team will pay every month to use this in production”.

I’d ask about a recent time the problem came up. What did they do, how long did it take, and who needed it done? If the answer stays hypothetical, so is the opportunity. You can learn a lot from someone who’ll never be a customer, as long as you keep it out of your sales forecast.

A business budget has conditions attached

A company with money doesn’t automatically spend it quickly. Someone has to recognize the problem, someone may have to approve the purchase, and if the software touches sensitive data, other people will ask how it stores that data and controls access. A useful product can get stuck between the person who wants it and the person who can authorize it.

A solo developer buying a small tool might decide in minutes, while a company spending more can take weeks of discussion. The bigger contract may justify that, but a small business needs enough cash and patience to wait.

Selling to companies also changes the product. You might need shared administration or a migration process, or a security questionnaire before they can start a trial. Those requests are reasonable from the buyer’s side, and they cost you time.

Segment by the expensive delay

Consider two hypothetical customers for a database migration tool. The first is experimenting with a side project, finds their current process annoying, and can work around it. They’re curious and happy to chat.

The second maintains an application that needs a database change before a contracted launch, and is worried about running the migration safely and explaining the result to colleagues. They’ll care much more about a dependable migration report than a clever interface, and they have a reason to finish soon. Both are developers, and putting them in one bucket hides the difference that matters.

My courses get some of that urgency from the calendar. The bootcamp opens enrollment for a cohort with a start date, the March 2027 edition has a waiting list, and the AI Workshop cohort opens enrollment on November 23 for Black Friday. A developer who’s been meaning to learn to build with AI for months has a date to decide by.

My starting point would be the recurring situation. Who runs into it, what does waiting cost them, and what do they do about it now? You don’t need to turn every answer into an invented financial return. Sometimes the cost is someone staying late, or a customer waiting for an answer, so describe it in terms the buyer recognizes.

Technical customers are good at evaluating

A developer can inspect an integration, test the export, and see whether the product fits their system. That can make selling easier, because you can publish good documentation and let the buyer check your claims without a demo call.

It also makes weak claims harder to sustain. “Connects to GitHub” is less useful than explaining which permissions you need and what happens when requests fail. GitHub’s own API guidance covers retries and rate limiting, and a buyer relying on your integration can expect you to handle ordinary operating conditions.

You don’t have to publish every implementation detail, but give people enough to decide whether trusting your tool is reasonable. With my apps the buyer gets the source, so they can read exactly what the app does.

Some technical customers also love customizing everything and will expect support for configurations you can’t afford to maintain, so set clear boundaries.

The people who use it may not buy it

For team software, the user and the buyer can be different people. A developer may love your tool and not be allowed to put company data into it. The team lead might have no budget left. Even when a founder approves the price, someone else may have to do the integration.

So “developers don’t pay” can be the wrong diagnosis. Sometimes the developer wants to pay and the offer doesn’t fit the purchasing process. In one team a company invoice is enough. In another, the person evaluating needs a seat-pricing explanation they can forward to their manager.

You can investigate this directly. Ask who approves the purchase and what they need to see, instead of answering every stalled trial with another feature. Then decide whether solving that obstacle is worth it for your kind of business, since supporting a procurement process makes sense for a large contract and not for a small subscription.

For the migration tool, I’d tie the evaluation to a change the team already has to ship. The developer picks one upcoming migration and runs the trial on a disposable copy of the database, with no production credentials. Agree on what they need to take back to the team, maybe a report of the proposed changes, and ask who’ll review it and when.

Then watch where the evaluation stops. A manager asking for an invoice after the review means you have a purchasing task. A report nobody opened because the migration was postponed is a question about timing. And when the team rejects the report because they still have to check every change by hand, the product hasn’t removed enough work, so ask which checks remain.

Keep a short note for each serious evaluation with the intended job, the person deciding, and where it ended. That’s more useful to compare than a count of enthusiastic signups.

Your price changes the relationship

A very cheap product can attract people who buy casually and need a lot of help. An expensive one can attract people who expect a lot of help because it’s expensive. So match the offer to the work it creates. A self-service product has to be understandable without a personal call, and a service that includes setup needs enough margin to do the setup properly.

This also changes how you read requests for a lifetime deal. Someone with a one-time need may be telling you a subscription doesn’t fit their problem, while someone who wants years of hosted service for almost nothing may not be a suitable customer.

I’d check whether the billing model fits how people get value before deciding the whole audience is cheap. A local utility, an API, and a team coordination service get used in different patterns. My apps run on the buyer’s machine, so a one-time price fits them, and the bootcamp is a 10-week program with lifetime access. I wrote about why I avoid recurring revenue in keeping my business small.

Distribution is part of the choice

If you already understand developers and know how to reach them, that’s worth a lot. It doesn’t guarantee a market, but you speak the language, recognize the complaints, and can put a tool in front of people who understand what it does.

For me that’s the blog and the newsletter. I wrote years ago about why an email list works for selling to developers, and the bootcamp waiting list is still a newsletter signup on its page.

Moving into an unfamiliar industry can mean learning how the work happens before you can even ask good questions. A developer spots a missing feature in five minutes, while understanding why a small logistics company still runs on a spreadsheet may take watching the handoffs between people. I’d happily do that learning for a problem I cared about, but not as a shortcut to easy customers. An audience with money that you can’t reach is still hard to sell to.

Look at behavior before changing direction

Before abandoning an audience, I’d look at a few concrete decisions. Which customers bought without negotiating? Which kept using the tool? What were they doing right before signing up? Did anyone recommend it to a colleague with the same problem?

Then I’d look at where things stalled. People stuck during setup need better onboarding. People who stop because the job is over may need a one-time offer, and weak demand may need a different problem altogether. A small paid-traffic experiment can show the same stalls with people who have no relationship with you. Switching from developers to “businesses” fixes none of them.

I’d also ask whether the customers who do buy support the business I want, since a handful of demanding accounts can bring in revenue and eat every available hour.

The next useful conversation is with someone who recently chose to pay or chose to walk away. Ask them what happened, and leave enough silence for an answer more specific than “developers are cheap”.

Want me to talk about your product? You can sponsor this site.