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.