Matthew F. OK cool. So I’d build a small signal research project for each product:
- 1.
Anypost: look for engineering teams publicly adding new transactional email flows or discussing a change to their email provider. Capture the exact flow, the provider they mention, the date, and the engineer connected to the work. That gives you a specific reason to reach out without guessing at their email volume or costs. For the strongest matches, you could make a quick screenshot showing how their publicly shared flow could look in Anypost.
- a.
Messaging...something like this: “John - I saw your [specific email flow] build. I’m with Anypost (we put transactional sends and delivery events in one API). Would love to hear how the flow's performing. I sketched how it could look in Anypost based on what you shared publicly. Want me to send over the screenshot?”
- 3.
Beekeeper: look for engineers publicly describing friction with their database client, or working across several database types Beekeeper supports. Save the exact comment or repo evidence, the databases involved, and a link. I’d start with 25 to 50 records, keep only the ones with a clear person-level signal, and write the first messages by hand.
- a.
Messaging...something like this: “John - saw your [specific migration] PR. I’m with Beekeeper Studio. I mapped out the tables it touches and put together a couple of read-only checks I’d run after that change. Want me to send over the screenshot and queries?”
The key is that each opener comes from something the engineer actually published. If the research only shows a company uses Postgres or SendGrid, I wouldn’t turn that into a claim that the person has a problem. PS. You're most likely going to have to slim down the messaging based on the variables. They all need to be under 300 characters in order to be included as a note with your connection request but this is kind of the angle I would take for all this. Hopefully this is helpful.
