1. Name the exact pain and the person who feels it
Write one sentence: who breaks, what breaks, and when. For example: "Platform engineers at 20 to 200 person SaaS companies who lose an hour every time a Terraform plan drifts from prod." Pick one job title to start: SRE, platform engineer, DevOps engineer, or the CTO at a small startup who does infra alone. If you cannot name the moment the pain happens, you cannot find the people having it.
2. Search for people complaining about it right now
Engineers describe their pain in public. Search GitHub issues on the tools you sit next to, like "flaky" or "slow" in the issues of Terraform providers, Argo CD, or GitHub Actions runners. Search Reddit's r/devops, r/kubernetes, r/sre and r/aws for phrases like "how do you handle" plus your problem. Do the same on Hacker News with hn.algolia.com, for example: "kubernetes cost" sorted by date.
3. Answer first, pitch never
Reply to those threads with a real answer that works even without your tool. Mention your tool only if it directly fits, and say you built it. For example: "We hit this with HPA flapping. Raising the stabilization window to 300s fixed most of it. I'm building a tool that flags this automatically, happy to share if useful." A good answer in r/devops is read for months.
4. Join the communities where engineers ask for help
Join the Slack workspaces engineers use: Kubernetes Slack, CNCF Slack, DevOps Chat, the HashiCorp community forum, and the Slack for the main tool you integrate with. Spend a week reading the help channels and answering questions. Note everyone who asks about your problem and message them directly after you have helped in public.
5. Send short, specific direct messages
Write to individual engineers who showed the pain. Reference their exact post and ask a question, not for a call. For example: "Saw your question in #kubernetes-users about cert-manager renewals failing silently. Did you end up fixing it? I'm building something for that exact case and would love 15 minutes to hear how you handle it today." Send 10 of these a day. Expect most to go unanswered and keep going.
6. Get it running in their environment on the call
DevOps buyers trust what runs on their own infrastructure, not demos. On the first call, offer to set it up together: a Helm chart, a single binary, or read-only cloud credentials. Ask what security review needs to see and answer in writing: what data leaves their network, what permissions you need, and how to remove it. One working install in a real cluster beats ten slide decks.
7. Ask for money early, keep it simple
After it works for a week, ask for a paid pilot. For example: "$300 a month for your team, month to month, and I'll fix anything you hit within a day." Small teams can often put this on a company card without procurement. If they say no to paying, ask what would need to be true to pay, and write it down.
8. Turn each customer into the next one
Ask every early user: "Who else do you know fighting this?" Engineers know engineers at other companies. Write a short public post on what you learned fixing their problem, with their permission, and share it in the same communities. Hulby, an AI cofounder, can do this daily for you by finding these threads and drafting the replies and messages.
Mistakes to skip
- Launching on Product Hunt before 10 people have used it in a real environment.
- Pitching in Slack help channels instead of answering the question asked.
- Targeting VPs of Engineering at large companies who need months of security review.
- Building more integrations instead of talking to the five people who already replied.
Want this done for your devops tool, every day?
Hulby finds the people asking for what you built, writes every reply and email, and keeps you on it until they pay. Free to start.
Find my first customersQuestions
Should I make my DevOps tool open source to get users?
Only if you are ready to support it. Open source brings users, not paying customers. If you do, keep a clear paid part, like hosting, SSO or team features.
How much should I charge the first customers?
Enough that it is a real decision, small enough to fit on a team lead's card. A few hundred dollars a month is a common starting point. You can raise it later.
What if companies need a security review?
Start with smaller companies where the engineer is close to the decision maker. Write a one-page doc on data, permissions and removal before anyone asks.
How long should getting 10 customers take?
It depends on how sharp the pain is and how many messages you send. Track replies per 10 messages each week. If replies are near zero, change the target or the problem, not the wording.