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. Sell to businesses with real budgets.

I understand the frustration behind it.

You show someone a product. They tell you how they would build it, suggest six features, and ask whether there is a lifetime deal. A business owner with an expensive problem sounds like a much better customer.

Sometimes they are. But “builders” and “businesses” are such broad groups that this advice can send you toward a different set of problems without explaining them.

I would rather know what happens to the buyer if they leave the problem unsolved.

Being able to build something doesn’t mean wanting to

A developer can build a deployment tool, an error dashboard, or an internal database browser. The ability to do so doesn’t mean that work deserves a place in their week.

Developers also have deadlines. They have projects that need attention and systems they would rather stop thinking about.

Imagine a small team preparing a customer launch. Their deployment process is unreliable. They can spend a few days improving it, or buy a service that meets their needs and return to the launch.

That is a different buying situation from a developer casually browsing tools on a Sunday. The people may have identical technical skills. The cost of delay is different.

I don’t find “they could code it themselves” very predictive. The question is what they would need to postpone to do it, and whether your product really removes that work.

A tool that needs days of setup can lose the comparison even if its feature list is impressive.

Enthusiasm can look like demand

People who enjoy building are often generous with attention.

They try new tools, discuss implementation choices, and give detailed feedback. If you also enjoy building, those conversations feel useful and encouraging.

They can be useful. They don’t establish willingness to pay.

A person might love your command-line tool as a technical idea while having no recurring need for it. Another might use the free version every day but have no reason to buy the paid features.

Neither person has tricked you. They are responding to the offer you made.

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

I would ask about a recent occurrence of the problem. What did they do? How long did it take? Who needed the work completed? If the answer stays hypothetical, I would treat the opportunity as hypothetical too.

You can learn a lot from someone who will never become a customer. You just need to keep that learning separate from a sales forecast.

A business budget has conditions attached

A company with money doesn’t automatically spend it quickly.

Someone needs to recognize the problem. Someone may need to approve the purchase. If the software handles sensitive information, other people may ask how it stores data and controls access.

Even 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. A company spending more can require weeks of discussion. The larger contract may justify that effort, but a small business needs enough cash and patience to wait.

Selling to companies can also change the product. You might need shared administration or a migration process. A customer may ask you to complete a security questionnaire before they can even start a trial.

These requests are reasonable from the buyer’s perspective. They also have a cost for you.

I would be cautious about leaving an easy-to-reach audience for a supposedly richer one without understanding how that audience buys. A higher price can come with a completely different working week.

Segment by the expensive delay

Consider two hypothetical customers for a database migration tool.

The first is experimenting with a side project. Their existing process is annoying, but they can work around it. They are curious about your tool and happy to discuss it.

The second maintains an application that needs a database change before a contracted launch. They are worried about running the migration safely and explaining the result to colleagues.

The second person may care much more about a dependable migration report than a clever interface. They have a particular job and a reason to finish it soon.

Both customers are developers. Putting them in one bucket hides the difference that matters.

You can make the same comparison among nontechnical businesses. A shop owner exploring a new reporting idea has different urgency from a shop owner unable to reconcile yesterday’s orders.

My starting point would be the recurring situation. Who encounters it? What does waiting cost them? What do they already do to resolve it?

You don’t need to turn every answer into an invented financial return. Sometimes the cost is a person staying late, or a customer waiting for an answer. Describe it in terms the buyer recognizes.

Technical customers can be good at evaluation

A developer can inspect an integration, test the export, and recognize whether the product fits their system.

That can make selling easier. You can publish useful documentation and let the buyer verify your claims without scheduling a demonstration.

It can also make 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 issues such as retries and rate limiting. A buyer relying on your integration is entitled to expect that you handle ordinary operating conditions.

You don’t have to publish every implementation detail. You do need to give someone enough information to decide whether trusting your tool is reasonable.

A technically capable customer who can confirm this independently may be easier to serve than a customer who needs personal guidance for every integration step.

The opposite can be true too. Some customers enjoy customizing everything and will expect support for configurations you cannot afford to maintain. Setting clear boundaries helps both of you evaluate the fit.

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 but lack permission to put company data into it. The team lead might have no budget left. Even when a founder approves the price, someone else may need to complete the integration.

“Developers don’t pay” can be a misleading diagnosis. Sometimes the developer wants to pay and the offer doesn’t fit the purchasing process.

A company invoice might be enough to complete the purchase. In another team, the person evaluating the product needs an explanation of seat pricing they can forward to their manager.

These are problems you can investigate directly.

Ask who approves the purchase and what they need to see. Don’t respond to every stalled trial by adding another feature.

Also consider whether solving those purchase obstacles is worthwhile for your kind of business. Supporting a particular procurement process may be sensible for a large contract and impractical for a small subscription.

For the hypothetical migration tool, I would make the evaluation about a change the team already needs to ship. Ask the developer to choose one upcoming migration and explain how they would approve it today. A safe trial could work on a disposable copy of the database, with no production credentials.

Agree on what the evaluator needs to take back to the team. Perhaps they need a report showing the proposed changes and enough information to investigate a failure. Ask who will review that report and when they expect to decide. This gives the trial a purpose beyond trying every button.

If evaluation requires substantial help from you, you could offer a small paid pilot. State the deliverable and the support it includes. Make clear what happens afterward, including whether there is any ongoing purchase obligation. For a tool someone can evaluate alone in an afternoon, adding a sales call and a pilot contract would create unnecessary work.

Then pay attention to where the evaluation stops. Suppose the developer produces the report, the team uses it in a review, and a manager asks for an invoice. You have a purchasing task to complete. Suppose the report never gets opened because the migration was postponed. Ask whether the new schedule gives them a reason to continue evaluating now or revisit the tool later.

If the team rejects the report because it leaves them checking every proposed change manually, the product hasn’t removed enough work. Ask which checks remain and whether your tool can reasonably handle them. You may discover a useful improvement, or a requirement outside the product you want to maintain.

Keep a short note for each serious evaluation. Record the intended job, the person deciding, and where it ended. Those notes give you something more useful to compare than a total of enthusiastic signups.

Your price changes the customer relationship

A very cheap product can attract people who buy casually and need substantial help. An expensive product can attract people who expect substantial help because it is expensive.

There is no price that makes customer service disappear.

What matters is matching the offer to the work it creates. A self-service product needs to be understandable without a personal call. A service that includes setup needs enough margin to perform that setup properly.

This also affects how you interpret requests for a lifetime deal. Someone with a one-time need may be telling you that a subscription doesn’t fit their problem. Someone who wants years of hosted service for almost nothing may be telling you they aren’t a suitable customer.

I would test 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 have different patterns of use. There is no reason they must all share the same pricing structure.

Distribution is part of the choice

If you already understand developers and know how to reach them, that is useful.

It doesn’t guarantee a market. It does reduce some of the work of discovering one. You speak the language, recognize the complaints, and can put a tool in front of people who understand what it does.

Moving into an unfamiliar industry can mean learning how work happens before you can even ask good questions.

A developer might recognize a missing feature in five minutes. Understanding why a small logistics company still relies on a spreadsheet may require watching the actual handoffs between people.

I would happily do that learning for a problem I cared about. I wouldn’t treat it as a shortcut to easy customers.

An audience you can reach and understand is worth considering, even if other founders complain about selling to it. An audience with money that you cannot reach remains difficult to sell to.

Look for behavior before changing direction

Before abandoning an audience, I would examine a few concrete decisions.

Which customers bought without negotiation? Which ones kept using the tool? What were they doing immediately before signing up? Did anyone recommend it to a colleague with the same problem?

Then I would look at where things stalled. People may start trials but get stuck during setup. Others use it successfully and stop because the job is over. You may also discover that your landing page assumes a problem the visitor never had.

These patterns suggest different changes. A setup problem needs better onboarding. A one-time job may need a one-time offer. Weak demand may require a different problem altogether.

Changing from developers to “businesses” doesn’t automatically fix any of those.

I would also ask whether the customers who do buy support the business I want. A handful of demanding accounts can generate revenue while consuming every available hour. As I’ve written about keeping my business small, time and independence belong in that decision too.

I would keep selling to builders when buying helps them complete work they care about and the relationship makes sense for both sides. I would sell to another group when I understand its problem well enough to make a better offer.

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.