Tanjim

I’m validating an idea and would appreciate feedback from people who’ve sold into mid-market or enterprise companies.

Problem I’ve observed: In B2B sales, especially complex deals, a surprising number of losses happen because the seller misreads the org structure.

You think you have the decision maker. You actually have someone with influence but no authority. The real economic buyer is two layers up. Or there’s an unseen blocker.

Mapping reporting lines manually using LinkedIn is slow and often guessy. Titles alone don’t reveal power structure.

The idea: Given a LinkedIn company page, automatically generate a visual org chart showing likely reporting lines and hierarchy depth. The goal is to make “power mapping” systematic rather than intuitive.

Target users: - SDRs / AEs running enterprise outbound - Founders doing B2B sales - RevOps teams inspecting deal risk

What I’m trying to validate: 1. Is misreading org structure actually a frequent cause of deal loss? 2. Do reps systematically map org charts today? 3. Would an automated approach meaningfully change behavior? 4. Is this a workflow tool or just a “nice to have”?

If this resonates and you’d like to be part of a small early group shaping it, I’m collecting a limited waitlist here:

https://www.dealtree.io/

Happy to share more technical details if helpful.

I’d genuinely value critical feedback — especially from people who’ve sold into complex orgs.

Thanks for sharing your perspective! In these complex sales, do SDRs use tools like LinkedIn to map the organization chart and effectively pitch the right solutions to the right people? I'm trying to understand how important and big enough the problem is for SDRs.

"Polling is repeatedly knocking on a door to see if anyone’s home. Webhooks are installing a doorbell that notifies you when someone arrives."

We just published a deep dive comparing webhooks vs. polling — not just the theory, but the tradeoffs teams face when building at scale.

- Polling: simple, reliable, but inefficient and often delayed.

- Webhooks: real-time and resource-friendly, but tricky to secure, monitor, and debug.

Curious to hear from HN: 1. Do you default to webhooks whenever possible? 2. Or is polling still underrated for certain use cases? 3. Any horror stories (or success stories) with either approach?

Webhooks have quietly become the backbone of modern SaaS integrations — Stripe, GitHub, Shopify, Slack… almost every product relies on them.

On the surface, they’re just POST requests. But at scale, teams end up reinventing a lot of the same infrastructure:

- Retry queues and exponential backoff - Dead-letter queues for failed events - Signature validation and replay protection - Monitoring and observability - Customer support when “the webhook didn’t fire”

This got me thinking: are we overdue for Webhook-as-a-Service (WaaS) to be treated as a first-class primitive, the way cloud providers gave us databases, queues, and object storage?

I wrote up a guide exploring what WaaS is, how it works, and why teams are increasingly adopting it.

Curious: 1. Has your team built webhook infra in-house? 2. Do you see WaaS becoming as common as using S3 or RDS instead of rolling your own? 3. Or is webhook delivery “too small” a problem to deserve its own category?

Would love to hear HN’s take.

I've been working on improving developer experience around event-driven integrations lately, and webhooks continue to be one of those deceptively "simple" tools that actually require quite a bit of infrastructure to handle properly at scale—retries, signature validation, queuing, DLQs, observability, etc.

I recently published a technical post that goes deep into what webhooks are, how they actually work under the hood, and why they matter in modern architectures: https://vartiq.com/blog/what-is-webhook-how-it-works-and-why...

Would love to hear how others are handling webhooks in production:

1. How are you queuing/processing them? 2. Do you use a third-party tool? 3. What kind of failure handling/retries do you implement?

Curious what the broader HN community thinks about the evolution of webhooks and whether we're due for better primitives around this.

Lol. But this can be pivoted into something fun and lovely for couples.

A lot to do in this space indeed. A clear blue ocean.

Thanks for pointing out. Edited. :)

That resonates. Testing asynchronous and multithreaded code for all possible interleavings is notoriously difficult. Even with advanced fuzzers or concurrency testing frameworks, you rarely gain full confidence without painful production learnings.

In distributed systems, it gets worse. For example, when designing webhook delivery infrastructure, you’re not just dealing with async code within your service but also network retries, timeouts, and partial failures across systems. We ran into this when building reliable webhook pipelines; ensuring retries, deduplication, and idempotency under high concurrency became a full engineering problem in itself.

That’s why many teams now offload this to specialized services like Vartiq.com (I’m working here), which handles guaranteed webhook delivery with automatic retries and observability out of the box. It doesn’t eliminate the async testing problem within your own code, but it reduces the blast radius by abstracting away a chunk of operational concurrency complexity.

Totally agree though – async, threading, and distributed concurrency all amplify each other’s risks. Communication and system design caution matter more than any syntax or library choice.