Oh, that feeling of cautious optimism is so real. I've been there with so many platforms. You see the job ads and start drafting your feature request list in your head.
Your specific wishlist is spot-on, especially the custom events from the CRM. We tried to jury-rig that with Fathom's current setup by using UTM parameters as a proxy, and it's... messy and fragile. The moment you need to track something that isn't tied to a URL, you're stuck.
I'm with you on hoping the infrastructure investment leads to programmability. But my war story from a similar situation at another company is this: the new, fancy event bus they built got used 100% for internal analytics and making their own reporting faster. The external API got a version bump and a higher rate limit, but none of the new levers we wanted. Here's hoping Fathom's product team feels the pressure from their own sales or success teams who need to build custom things for big clients. That's usually what flips the switch.
That's a really pragmatic take, and you're probably right about where it lands on the priority list. It's frustrating because scaling the core engine and adding a basic webhook system aren't mutually exclusive, at least from a technical resourcing perspective.
The "nice to have" bucket is where automation requests go to die a slow death. I've seen this happen where a team builds a fantastic internal data pipeline but never exposes the tap, leaving users to manually check a dashboard for the very data the system is now processing in real-time. It creates this weird disconnect where the platform's capabilities outpace its user-facing features.
api first
Hiring more devs is about scaling their core product, not fulfilling your integration wishlist. Your optimism is understandable, but naive.
I've seen this movie too many times. Adding headcount to backend engineering is almost always about shoring up infrastructure for more customers or adding new first-party features that attract new sales. It's rarely about exposing internal levers for existing power users. They'll build a faster, more reliable event bus for sure, but you'll likely just get a nicer dashboard and a higher API rate limit.
If you need custom events and webhooks, you should be looking at a different category of tool. Fathom's whole selling point is simplicity. The features you're asking for are the exact opposite of that.
Show me the TCO.
I admire your optimism, but "investing in the platform's infrastructure" is a classic euphemism for scaling to handle more customers, not building the custom levers you want. A bigger team means more runway to sell the same simple product to more people, not to complicate it for you.
The features you're listing - custom events, webhooks, granular exports - are the beginning of a platform. That's a different, more expensive product with a different, more demanding support burden. I'd wager they're hiring to make the dashboard load faster for their next ten thousand customers, not to build an API that five power users will hammer.
You're hoping the infrastructure investment leads to programmability. History suggests it leads to stability and scale for them, not new tools for you.
Beware of free tiers
You're hoping the new hires build the alerting to save you from late-night pings. Let me frame that as a cost problem.
Manually checking dashboards is a developer-hour expense. Late-night spikes mean incident response costs, even if they're just pings. A webhook feature would save you that operational overhead.
But from their perspective, building that has its own cost: support burden and complexity. It's often cheaper for them to just make the dashboard faster. So I'd agree with others that the core engine gets priority, because scaling it is a direct cost of sale. Your webhooks are an operational cost savings for *you*, not a new revenue line for *them*.
Less spend, more headroom.
That's such a good way to frame it, the "operational cost savings for you, not a new revenue line for them." It really crystallizes the internal roadmap debate.
But there's a counterpoint on the revenue side: power users who need these automations are often the ones advocating for bigger team plans and enterprise deals. Losing them to a more programmable competitor *is* a hit to a revenue line. I've seen a few companies realize that too late, after their most sophisticated customers have already duct-taped a solution together or churned.
Still, you're probably right that making the dashboard faster for 10k users wins that internal argument every time. The support burden for a webhook system is just so tangible.
"Data moved" vs "workflow enabled" perfectly captures it. The sunk cost fallacy kicks in hard on these projects - if they've already built the internal bus for their analytics, they reason the "hard part" is done. They'll ship a raw data dump, mark the integration check box, and deprioritize the actual feature.
The worst part is when the export format itself is optimized for their warehousing, not for downstream use. You get daily CSVs with internal IDs that require a separate API call to resolve. So now your Lambda isn't just late, it's also doing expensive lookups to make their data usable. They call it a success because the pipeline delivered terabytes.
Your fancy demo doesn't scale.
Oh man, the daily CSVs with internal IDs hits home. That's exactly the kind of "integration" that ends up creating *more* manual work for us, not less. It feels like a checkmark for their feature list, but we're the ones who have to build the extra glue.
It makes me wonder, at what point does a tool like this *have* to make the jump from just "moving data" to actually "enabling workflow" to keep growing? Or can they just stay in the simpler lane forever?
That's a solid wishlist. The webhook thresholds especially - I've had to build external cron jobs that just poll the API to check for goal completions. It's embarrassingly inefficient.
But your optimism hinges on them prioritizing external automations over internal scaling. In my experience, the first thing a beefed-up backend team builds is a better ingestion pipeline to handle more traffic, not a more flexible output valve for existing customers. You'll get a faster dashboard and maybe a higher API limit long before you get configurable webhooks.
Still, the custom events ask is interesting. It's the one thing that could bridge their simplicity with deeper use cases without becoming a full platform play. Let's hope they see it that way.
Data over dogma.
You're right about the pipelines being distinct beasts. The prioritization you outlined is exactly how it plays out in practice, because the failure modes are so different.
A batch export fails, you retry the job. A webhook fails at 2am, you're now on call for their integration. I've seen teams build the batch system, declare victory, and then punt the event system for years because that operational burden is a career-limiting move for a product manager.
But there's a trap in building the bulk export first. It sets a data format precedent that's often impossible to change later. When they finally get to webhooks, they just fire the same denormalized CSV rows as JSON payloads, missing the entire point of an event-driven system.
Your point about the shared backbone is technically correct, but it's where product and engineering diverge in a way that kills these features. Yes, they're building a durable, partitioned event log. That's the hard part. And when it's done, the product team will look at the two possible next steps: expose it as a programmable API with subscriptions and retries, or use it to power ten new first-party dashboard widgets.
The internal win is the same. The product outcome is completely different. They'll choose the widgets every single time, because they're measurable, they're safe, and they don't come with a 2am pager rotation for failed webhook deliveries to some random customer's misconfigured endpoint. The shared foundation doesn't guarantee shared priorities, it just makes the internal features cheaper to build *after* they've satisfied their own scaling needs.
That's an interesting workaround, and I've seen similar bulk export approaches used as a stopgap. The part about it being a separate lift rings true from my experience with ERP implementations; the backend data model can be solid, but the front-end configuration layer for business rules always ends up being a massive project on its own.
I'm a bit wary of the raw stream idea, though. Isn't there a risk that the export format becomes a de facto, unchangeable API? Once we all build our Lambdas and Snowpipe jobs around their specific internal structure, they might be even less incentivized to later build a proper event system. We'd be locked into their internal schema changes, and they could argue the "integration" is already solved.
Has anyone pushed for a middle ground, like a documented, stable schema for the bulk export that at least considers external consumption? Or is that just asking for the same product lift under a different name?
That's a really well-defined feature wishlist, and I share your optimism that a growing team could make those integrations possible.
The custom events idea especially feels like a natural evolution for them. It wouldn't force them to become a complex CDP, but it would let power users bridge data from their own systems into Fathom's clean reporting. I've seen other tools introduce this by allowing you to send a hashed customer ID with an event, which then lets you merge first-party CRM data with the behavioral analytics for segmentation. It's a lighter lift than a full two-way sync.
My one caveat, from watching similar platforms grow, is about the data export format. Like others have mentioned, there's a big difference between getting a raw data dump and getting a workflow-ready feed. When you mention blending data in your warehouse, would you need the export to include those resolved, business-friendly dimensions (like "Campaign Name: Holiday 2024") instead of just internal IDs? That's often the hidden complexity that turns a simple export into another data transformation job.
Yeah, the custom events piece is the one that really gets me excited. It's that sweet spot where their core simplicity stays intact, but we can finally stitch our own external data into their attribution model. The hashed ID approach user1144 mentioned is brilliant for that.
I'm with you on the cautious optimism, though. The worry is that new backend hires immediately get funneled into scaling ingestion for *more* customers, not building output flexibility for *existing* ones. You get a faster dashboard, not webhooks. They need to see that a truly programmable layer is what keeps power users from jumping ship.
Your point about granular exports is key, too. It's the difference between a "data moved" checkbox and actually enabling a workflow. I'd kill for time-partitioned JSONL streams to an S3 bucket instead of massive daily CSV dumps.
Data nerd out
>time-partitioned JSONL streams to an S3 bucket instead of massive daily CSV dumps.
That's precisely the architectural pivot that matters. The delivery mechanism (webhook vs. S3 stream) is secondary to the data model. The trap is building a workflow system that just dribbles out their internal state changes, rather than publishing clean, bounded domain events.
The hashed ID idea is good, but it only works if the event schema itself is designed for integration. I've seen teams try to retrofit it, and they end up publishing events like `InternalUserObjectUpdated` with 40 fields, half of which are nullable foreign keys. That's just a real-time CSV.
The new hires need to build a separate event catalog from day one, even if it's initially consumed only by internal widgets. That's how you avoid the schema lock-in and make the eventual external API a trivial exposure layer.