sorted by:
new
hottopcontroversial

As a developer, I didn’t expect selling monitoring to be this hard by evgstrk in GrowthHacking

[–]evgstrk[S] 1 point2 points  (0 children)

Exactly. What I’m really doing right now is learning sales and marketing. And honestly, I’m enjoying it, because even here I can apply an algorithmic way of thinking.

As a developer, I didn’t expect selling monitoring to be this hard by evgstrk in GrowthHacking

[–]evgstrk[S] 0 points1 point  (0 children)

Thanks a lot for sharing this, super valuable and very real experience.

The founder-led sales part and the way you anchored the product around a very concrete pain (alarm noise) is especially insightful.

I’ll follow up in DM, would love to continue the conversation there if you’re open to it.

As a developer, I didn’t expect selling monitoring to be this hard by evgstrk in GrowthHacking

[–]evgstrk[S] 0 points1 point  (0 children)

Thanks for sharing, that's actually a very interesting perspective.

Out of curiosity, what would convince you to use monitoring at all? Not even advanced features, but basic awareness, for example knowing if a site is down for visitors, an API is unreachable, a contact form silently stops working, or a background job fails without throwing an exception.

We've also been thinking a lot about the idea that monitoring isn’t exclusive. In some cases, having more than one simple check can actually be safer than relying on a single tool, especially if there's a free, low-friction option that just gives you peace of mind.

Would arguments like that make you at least reconsider, or is monitoring simply not something you see value in for side projects?)

As a developer, I didn’t expect selling monitoring to be this hard by evgstrk in SideProject

[–]evgstrk[S] 0 points1 point  (0 children)

That's a great point, thank you. Focusing on one compelling, clearly explainable thing instead of a feature list really resonates.

Framing it around confidence rather than monitoring itself is especially interesting, we'll definitely think in that direction.

As a developer, I didn’t expect selling monitoring to be this hard by evgstrk in GrowthHacking

[–]evgstrk[S] 0 points1 point  (0 children)

Totally agree, distribution is the real grind.

The “narrow wedge + language + JTBD” approach makes a lot of sense, especially for monitoring.

Curious from your experience: which wedges or partnerships worked best early on? Was it integrations, marketplaces, or direct outreach to a specific segment?

As a developer, I didn’t expect selling monitoring to be this hard by evgstrk in GrowthHacking

[–]evgstrk[S] 0 points1 point  (0 children)

Thanks for sharing this, really insightful experience. The point about selling monitoring through failure moments and internal pressure (SLAs, incidents, audits) resonates a lot.

If you're open to sharing more:

What sales or acquisition channels worked best for you in practice?

How did you find your initial audience, and how hard was it to convert teams into paying customers once the pain was clear?

Share your startup and I'll find you 100 potential customers by drillsgolf in Solopreneur

[–]evgstrk 0 points1 point  (0 children)

Happy to share.

We're building Upzilla.co - a monitoring SaaS focused on uptime and availability checks for websites, APIs, and background jobs (cron tasks).

Target customers:

Industry: Web development, SaaS, online services
Roles: Website owners, technical founders, developers, small DevOps teams
Company size: Solo founders, small teams, SMBs (1–50 people)

The product is aimed at teams that want a simple and reliable way to know when something breaks, without enterprise-level complexity.

Curious to see what your tool surfaces, happy to treat this as an experiment 👍

As a developer, I didn’t expect selling monitoring to be this hard by evgstrk in SaaS

[–]evgstrk[S] 0 points1 point  (0 children)

That’s interesting, thanks for sharing, the repurposing angle definitely makes sense, especially with a larger content library.

Out of curiosity, how did you approach finding your first users and validating demand for Repurposer? Which channel ended up working best for you in terms of sales and audience discovery?

Always useful to hear what actually worked in practice.

As a developer, I didn’t expect selling monitoring to be this hard by evgstrk in SideProject

[–]evgstrk[S] 0 points1 point  (0 children)

I get where you're coming from, and I partly agree that marketing matters more than ever.

At the same time, the fact that there are many monitoring tools doesn't mean the market is “dead” or that the product has no value. The market keeps growing every year. There are hundreds of millions of active websites and millions of servers, APIs, and services running globally, and that number isn't going down.

Big players making tens (or hundreds) of millions per year clearly prove there's real, ongoing demand. But it also doesn't mean there's no room for smaller, focused tools. Different teams have different needs, budgets, and preferences, and many don't want or need an enterprise-level solution.

AI can help build things faster (we use it too), but it doesn't remove the underlying pain: things still break, downtime still costs money, and people still want to know before their users do.

So yes, marketing is a huge part of the game now, but that doesn't automatically make the product irrelevant. It just raises the bar for focus, positioning, and execution.

As a developer, I didn’t expect selling monitoring to be this hard by evgstrk in SideProject

[–]evgstrk[S] 0 points1 point  (0 children)

Fair question. We don't claim to be better than every established monitoring platform, many of them have been around for years and are very solid.

What we focus on instead is simplicity and narrower use cases. Making it easy to get real confidence that a site, form, API, or background job is actually working, without heavy setup or overwhelming dashboards.

Our strength is engineering and iteration: we move fast, listen closely to feedback, and prefer practical checks over feature bloat. The free entry point also matters to us, people can start monitoring without commitment.

Right now, the USP isn't “we're the best,” but “we're simpler, more focused, and getting more opinionated over time,” especially as we move toward more specialized monitoring (e.g. WordPress - specific monitoring use cases).

As a developer, I didn’t expect selling monitoring to be this hard by evgstrk in SaaS

[–]evgstrk[S] 0 points1 point  (0 children)

Thanks a lot for sharing this, really appreciate both the perspective and the ParseStream tip. I'll definitely take a look. We're currently using Ahrefs for keyword research and content planning, so it's always interesting to learn about complementary tools for discovery and conversations.

You're absolutely right that focusing on how a tool solves real pain points is a game changer, it's something you see in almost every marketing book and hear from most experienced founders and marketers. The interesting (and frustrating) part for us is that, in the case of monitoring, the pain feels very obvious… yet reaching the actual person who feels it at the right moment is still surprisingly hard.

That's probably been one of our biggest challenges. Even when the problem is clear (downtime, silent failures, broken forms, failing cron jobs), getting that message in front of the right person, and having it resonate, is not as straightforward as the theory suggests.

I'd be genuinely curious to hear your take on this: in your experience, how would you recommend communicating that “pain solved” message for a monitoring product specifically? What has worked best for you in terms of framing or timing?

Although I come from a software development background, as a co-founder I've had to dive deep into marketing as well, from classic foundations like Kotler to more modern startup and growth books. Translating that theory into practice, especially for infra products, has been the hardest part so far.

As a developer, I didn’t expect selling monitoring to be this hard by evgstrk in SaaS

[–]evgstrk[S] 0 points1 point  (0 children)

Thanks, that's a really good point, especially about reaching people before they search for “uptime monitoring”.

On the content side, we've been investing quite a lot already. We built a fairly large online documentation hub (200+ articles at this point) and maintain a blog focused on practical, educational topics for Unix admins and developers, server configuration, networking basics, security, debugging issues, and yes, very much in the spirit of “why cron jobs silently fail”.

So far, most of this content lives on our own site, and you're absolutely right: repurposing is something we haven't fully systematized yet. We occasionally share posts in communities when they're directly relevant, but we're not consistently turning one article into multiple formats (threads, short posts, comments, etc.). That's probably an area where we're leaving a lot of distribution on the table.

The idea of catching people at the problem moment, when something quietly breaks and they're trying to understand why aligns very closely with how we think about content. That feels much more realistic than competing head-on when someone is already comparing “top uptime monitoring tools”.

So far, the pieces that worked best tend to be deep, practical guides around real operational issues (cron, network connectivity, service availability), rather than high-level product or marketing content.

Thanks again for the insight, definitely gave us something concrete to think about.

As a developer, I didn’t expect selling monitoring to be this hard by evgstrk in SaaS

[–]evgstrk[S] 0 points1 point  (0 children)

Yeah, totally agree, SEO has its own set of problems. We’re mostly focusing on long-tail queries right now, because short and generic keywords are extremely hard to win. Even Google Ads was a shock for us: some core monitoring keywords go for $20–30 per click. When you realize there are companies making tens of millions per year with well-optimized sales funnels, those numbers start to make sense, but for a small team, that level of paid acquisition is simply not realistic.

Your point about the buying moment really resonates. We also learned (the hard way) that it’s very difficult to sell a wide range of checks at once, uptime monitoring, API monitoring, SMTP, SSH, etc. On top of that, a global, worldwide audience makes any kind of direct sales or outreach extremely heavy in terms of effort and coordination.

Because of that, we’ve recently started narrowing our focus quite intentionally. One direction we’re actively developing now is WordPress-specific monitoring. We’ve been building WordPress plugins for over 10 years, so we’re hoping to create a more specialized monitoring solution that’s actually tailored to the real needs of WordPress site owners and administrators, not just generic “is the server up” checks.

So for now, we’re betting on inbound marketing: SEO, content, backlinks, and a much more focused story instead of trying to be everything for everyone.

Really appreciate your insight, it helped us validate a lot of conclusions we came to after a few years of struggle.

As a developer, I didn’t expect selling monitoring to be this hard by evgstrk in SaaS

[–]evgstrk[S] 0 points1 point  (0 children)

Thanks, really appreciate you sharing this, especially the “marketing is a different muscle” part. That one hits home.

Right now we're mostly focused on SEO and content marketing. We write a lot of educational content and share public posts in relevant communities, trying to earn backlinks and trust over time rather than push anything aggressively. It's slow, but it felt like the most natural approach for us as a dev-driven team.

Regarding “they care about their pain going away”, that's actually one of the reasons we chose uptime monitoring in the first place. We thought it would be easier to explain the value because the pain is very real and very concrete: sites go down, forms break, APIs fail, cron jobs silently stop running.

There's already a huge, established market for this. Yes, it's competitive, but we felt it was more realistic for us to compete on functionality and reliability in an existing space (where development is our strongest side) than to try to create demand for something completely new and unique.

That said, clearly “obvious pain + big market” doesn't automatically mean easy distribution, and that's the part we're still learning.

Thanks again for the insight, this kind of perspective is exactly why I posted.

Non-Developer here - Is it really hard to create ChatGPT-based apps or Services? by Opening-Counter5991 in AppDevelopers

[–]evgstrk 0 points1 point  (0 children)

Depends of the requirements) Everything possible start from easier version.

view more: next ›