While I typically agree that buying is better than building this was one case where building still made the most sense for us. See the post below:
https://zapier.com/blog/2012/10/14/when-you-should-build-not...
Here's a portion of an email I wrote to another email company about why we built this:
I've run email for multiple companies now, and the biggest problem I've always faced is a disconnect between what data the third party holds vs. what data is in my internal database.
There's also a bit of an issue with us (Zapier) that a lot of things happen on when a user isn't on site so we have to use the API to constantly push data to the third party if we want it to work. This requires us to either 1) figure out what data we should be pushing or 2) push everything.
The first part is annoying because it's hard to predict what is needed and developers hate getting requests to add just one more piece of data to the email service.
The second part is not great because now we spend a bunch of resources sending everything and the third party can essentially replicate our database or we push so much data that it becomes cost prohibitive.
So we just built a simple logic builder around MailGun that handles sending email. It's not perfect (i.e. we don't have great analytics and all our emails go out at the same time ever day), but we can literally segment on anything. Every single table in our database. And for a service with use cases all over the place this saves me from sending stupid generic emails or from sending an email about sales to developers or an email about github to a marketer.
edit: my hope is still that a 3rd party service figures this out because I'd much rather pay someone for this than build it. But if building is the only way you get features you need, then build you must.
P.S. I think Bryan might have spent a weekend hacking on this. So not a ton of resources lost especially considering that you can't spend all your brain waves hacking on your core product or you'll go mad.