u/kschecker

I run a small B2B dev-tools SaaS, and I want an honest gut-check on the part I haven't cracked: getting into the market. Full transparency, this is my own product, so flag me if this crosses a line.

Quick context. I built an edge proxy that sits in front of GraphQL and REST APIs. You keep your schema as the source of truth, and it handles caching, security and request insights on top, without per-seat pricing. It's EU and GDPR-native, self-serve SaaS.

This week I had a long call with a more established player in my space. Their honest take stuck with me: the product is rarely the hard part, distribution is. They pushed me to rethink the whole go-to-market, including whether self-serve SaaS is even the right motion for infrastructure like this, versus design partners, sales-led, or on-prem for larger accounts.

I don't think they were wrong about the core point. I can build. What I haven't found is a repeatable way to get a technical B2B product in front of the right buyers, who in my case are engineering teams and CTOs.

What I'm genuinely asking the people here:

- Early acquisition: when you had no audience, how did you actually reach your first customers? What outbound or community motion got real replies, and what wasted months?

- Design partners: how did you find and convince your first design partners, and what did you offer them to say yes?

- Channels for technical buyers: what actually reached engineering teams for you? Does LinkedIn work for this audience, or is it mostly founders and execs there and devs are reached elsewhere?

- Did "the product is easy, distribution is hard" hold true for you, and what specifically broke the deadlock?

I'm not after "do more marketing." I want the specific thing that gave you traction when you were where I am now.

Happy to show the product for context. I'll drop a link in a comment so this stays a discussion, not a pitch.

A bit of honest context:

I recently had a conversation through the GraphQL network that got me thinking, and I'm now evaluating which direction to take a product I'm working on. So I'd genuinely value the experience of the people here.

The product is a GraphQL caching CDN / edge proxy: it sits in front of your GraphQL API and handles caching driven by your schema (with automatic invalidation), plus security and rate limiting.

The decision I keep going back and forth on: is something like this better run on-premise in your own infrastructure, as a managed SaaS, or do I need to offer both?

A few angles I'd love input on:

- If you run GraphQL in production, which would you reach for first, and why?

- For SaaS: is routing your query traffic through a third party an actual problem for you (compliance, data residency, internal policy), or a non-issue in practice?

- For on-prem: would you genuinely want to operate this yourself, or is "someone else runs it" part of the whole appeal?

And honestly, I'm also just trying to figure out how teams who'd care about this even discover tools like it. So if you remember how you found your current gateway or CDN, that helps too.

Blunt answers very welcome. I'm orienting, not selling.

https://preview.redd.it/nywgj9tmm88h1.png?width=1672&format=png&auto=webp&s=572baa28f1dcfa802dbb393ee1279bdadb841bb6

Every team scaling GraphQL eventually asks "can't we just put a CDN in front of it?" It sounds obvious, since CDNs made REST fast and cheap. Then you try it and hit the wall fast.

I wrote up the practical version of why GraphQL caching is its own problem:

• One endpoint, one verb, the query in the body, so a stock CDN can't even tell two requests apart
• Generating a stable cache key is the easy 80%
• Invalidation is the hard part: one mutation can stale fragments of many unrelated cached responses (profile page, comment list, search result, all under different keys)
• Lists/pagination, mutations that don't return the changed entity, per-viewer auth, partial responses... each adds a wrinkle
• Push it to the edge and you inherit a distributed-systems problem on top

I'm curious how people here actually handle invalidation in production. Surrogate keys with a purge API? TTL-only and live with staleness? Something custom? And where does it bite you most: lists, auth scoping, or the edge propagation?

The full article is available at DEV. You'll find the link in the thread