Sales for Developers: The Anti-Cringe Guide to Your First 10 Customers

"I didn't become a developer to do sales calls." If this thought has crossed your mind, you're in the right place.

Here's the truth: you don't need to become a salesperson. You need to become someone who's really good at understanding problems and connecting people with solutions. Which — plot twist — is exactly what good engineering is.

Why developers make better salespeople (when they stop trying to "sell")

Traditional sales is: pitch features, overcome objections, close the deal. It feels manipulative because, often, it is.

Developer sales is: understand the problem deeply, show how your solution works, let the product speak. No closing techniques needed. No "SPIN selling." Just honest conversations about real problems.

The best developer-founders I know sell by:

• Asking questions like they're debugging a system
• Showing, not telling (a 2-minute demo beats a 20-minute pitch)
• Being honest about limitations ("we don't do X yet, but here's our workaround")
• Following up with value, not pressure

The anti-cringe sales framework

Step 1: Find people who already have the problem (15 min/day)

Go where your potential users discuss their problems:

• Reddit: r/SaaS, r/startups, your industry subreddits
• Hacker News: "Ask HN" threads related to your space
• Twitter/X: search for complaints about the problem you solve
• Stack Overflow, Discord servers, Slack communities

You're not looking for people to pitch. You're looking for people who are actively struggling with the thing you built a solution for.

Step 2: Help first, mention second (10 min/interaction)

When you find someone with the problem, help them. Give a genuine answer. Share your expertise. Then, if it's natural: "By the way, we built a tool that does exactly this. Happy to show you if you're interested."

This is not selling. This is being a helpful person who happens to have built something relevant.

Step 3: Direct outreach that doesn't feel like spam (20 min/message)

When you need to reach out proactively, the key is research. Spend 15 minutes actually understanding the person and their company before writing a single word.

A good developer outreach message looks like:

"I saw your team's blog post about migrating from X to Y. That usually creates Z problem with data pipelines. We built [product] specifically for teams going through this transition — it handles [specific thing] automatically.

Would it be useful to see a quick demo? No pressure either way."

Notice: no "I hope this email finds you well." No "leveraging synergies." Just one engineer talking to another about a real problem.

Step 4: The demo that converts (30 min)

When someone says yes to a demo, don't open with slides. Open with questions:

• "Walk me through how you currently handle X"
• "What's the most annoying part?"
• "What have you already tried?"

Then show — live, on their actual use case if possible — how your product solves it. Let them see the "before and after" in real time.

End with: "Does this seem like it would actually help?" Not "When can we get you started?" The difference matters.

Step 5: Follow up like a human (5 min)

After a demo, send a genuine follow-up:

• A summary of what you discussed (shows you listened)
• A link to try the product
• An answer to something they asked that you didn't know on the call

Then follow up once more after a week. If they're not interested, move on. No "just checking in" emails. No guilt trips. You're a developer, not a used car dealer.

Scaling past the first 10

Manual outreach gets you your first 10 customers and teaches you what resonates. But you're a developer — you know that manual processes don't scale.

After your first 10 customers, you should know:

• Which type of company converts best
• What message angle gets the most replies
• Which channels work (email? LinkedIn? Reddit?)
• What objections come up and how to address them

Now you can automate the pattern. Tools like Selda can take your product context and run the outreach at scale — finding the right audience, crafting research-backed messages, and executing across the channels that work for your specific product and market.

The point isn't to replace the genuine conversations. It's to automate the research and reach so you can have more of them.