HackerTrans
トップ新着トレンドコメント過去質問紹介求人

Tanjim

no profile record

投稿

[untitled]

1 ポイント·投稿者 Tanjim·2 か月前·0 コメント

[untitled]

1 ポイント·投稿者 Tanjim·2 か月前·0 コメント

Show HN: Ilove4o – a simple way to keep using GPT-4o

1 ポイント·投稿者 Tanjim·5 か月前·1 コメント

Ask HN: Validating an idea; automated org chart / power mapping for B2B sales

dealtree.io
1 ポイント·投稿者 Tanjim·5 か月前·1 コメント

Ask HN: Do B2B deals stall more from "org blindness" than product fit?

6 ポイント·投稿者 Tanjim·6 か月前·6 コメント

[untitled]

1 ポイント·投稿者 Tanjim·10 か月前·0 コメント

[untitled]

1 ポイント·投稿者 Tanjim·10 か月前·0 コメント

コメント

Tanjim
·5 か月前·議論
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.
Tanjim
·6 か月前·議論
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.
Tanjim
·10 か月前·議論
"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?
Tanjim
·12 か月前·議論
Thanks for pointing out. Edited. :)
Tanjim
·12 か月前·議論
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.