Get started

If you are building a monitoring tool, your interviews should be about the last incident, not your product. The people who feel the pain are on-call engineers, SREs and solo founders running their own infra. Here is how to find them for free and what to ask.

All guidesFor founders of a monitoring tool

1. Pick one narrow user

Monitoring is broad, so choose one person first. Good options are the solo SaaS founder on a $20 VPS, the DevOps engineer at a 10 to 50 person startup, or the agency dev maintaining 30 client sites. Write one sentence describing them and only interview people who match it.

2. Find them where they complain

Search Reddit r/devops, r/sysadmin, r/selfhosted and r/SaaS for threads like "alert fatigue", "Datadog bill" or "site went down and I didn't know". Check Hacker News comments on outage postmortems and the DevOps Chat and SRE Discord servers. Note the people who described a real incident in their own words.

3. Send a short, honest ask

Message them directly and reference what they wrote. Example: "Saw your post about finding out from a customer that your API was down. I'm researching how small teams handle monitoring. Could I ask you 5 questions on a 15 minute call? Not selling anything." Send 20 of these a day and expect a few yeses.

4. Start with the last incident

Open with "Tell me about the last time something broke in production." Then follow up with "How did you find out?", "How long until you knew the cause?" and "What did you do in the first 10 minutes?" Real stories beat opinions about monitoring in general.

5. Map their current stack and cost

Ask "What do you use today for uptime, logs, metrics and alerts?" and "What do you pay for it each month?" Then ask "What did you try before and why did you stop?" Tools they abandoned show you what does not work.

6. Dig into alerting pain

Ask "How many alerts did you get last week, and how many mattered?" and "When did an alert wake you up for nothing?" Also ask "Who gets paged, and how?" Alert noise and missed alerts are where switching decisions usually happen.

7. Test willingness to pay without pitching

Near the end, ask "If this problem disappeared tomorrow, what would that be worth to you per month?" and "Who would need to approve that spend?" If the pain is strong, describe your tool in one sentence and ask if they want to try it this week. A yes to a trial or a paid pilot counts as a signal. Polite interest does not.

8. Log answers and spot patterns

After each call, write down the incident, current tools, monthly spend and exact phrases they used. After 10 calls, look for the same complaint showing up three or more times and build for that first. Hulby, an AI cofounder, does this outreach and note-taking daily for founders who want help keeping it going.

Mistakes to skip

  • Asking "Would you use a tool that does X?" instead of asking about the last real incident.
  • Interviewing other founders building monitoring tools instead of the people on call.
  • Pitching your dashboard in the first five minutes and turning the call into a demo.
  • Ignoring current spend, so you never learn what budget you are competing for.

Want this done for your monitoring 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 customers

Questions

How many interviews do I need?

Aim for 10 to 15 with one type of user. Patterns usually show up by then. If they don't, your user type is too broad.

Should I interview people at big companies?

Only if they are your target. Large teams have procurement and existing contracts, so early on, small teams and solo founders buy faster.

What if people won't get on a call?

Offer to send 3 questions they can answer in a reply. Many engineers prefer text and will write detailed answers.

When do I ask them to pay?

At the end of a call where they described a painful, recent incident. Offer a paid pilot or early access price right then.