Episode Show Notes & Transcript
Corey: Welcome to AWS Morning Brief: Whiteboard Confessional. I’m Cloud Economist Corey Quinn. This weekly show exposes the semi-polite lie that is whiteboard architecture diagrams. You see, a child can draw a whiteboard architecture, but the real world is a mess. We discuss the hilariously bad decisions that make it into shipping products, the unfortunate hacks the real-world forces us to build, and that the best to call your staging environment is “theory”. Because invariably whatever you’ve built works in the theory, but not in production. Let’s get to it.
nOps will help you reduce AWS costs 15 to 50 percent if you do what tells you. But some people do. For example, watch their webcast, how Uber reduced AWS costs 15 percent in 30 days; that is six figures in 30 days. Rather than a thing you might do, this is something that they actually did. Take a look at it. It's designed for DevOps teams. nOps helps quickly discover the root causes of cost and correlate that with infrastructure changes. Try it free for 30 days, go to nops.io/snark. That's N-O-P-S dot I-O, slash snark.
Welcome once again to the AWS Morning Brief: Whiteboard Confessional. Today I want to talk about, once again, an aspect of writing my Last Week in AWS newsletter. This goes back to before I was sending it out twice a week, instead of just once, and my needs weren't that complex. I would gather a bunch of links throughout the week: I would make fun of them and I had already built this absolutely ridiculous system that would render all of my sarcasm from its ridiculous database where it lived down into something that would work to generate out HTML. And I've talked about that system previously, I'm sure I will again. That's not really the point of the story.
Instead, what I want to talk about is what happened after I had that nicely generated HTML. Now, I've gone through several iterations of how I sent out my newsletter. The first version was through a service known as Drip, that's D-R-I-P. And they were great because they were aimed at effectively non-technical folks, by and large, where it’s, “Oh, you want to use a newsletter. Go ahead.”
I looked at a few different vendors. MailChimp is the one that a lot of folks go with for things like this. At the time I was doing that selection, they were having a serious spam problem. People were able to somehow bypass their MFA. Basically, their reputation was in the toilet and given my weird position on email spam, namely, I don't like it, I figured this is probably not the best time to build something on top of that platform, so that was out.
Drip was interesting, in that they offered a lot of useful things, and they provided something far more than I needed at the time. They would give me ways to say, “Okay, when someone clicks on this link, I can put them in different groups, etcetera, etcetera.” You know, the typical email, crappy tracking thing that squicks people out. Similarly to the idea of, “Hey, I noticed you left something in your cart. Do you want to go back and buy it?” Those emails that everyone finds vaguely disquieting? Yeah, that sort of thing. So, 90 percent of what they were doing, I didn't need, but it worked well enough, and I got out the door and use them for a while.
Then they got acquired, and it seemed like they got progressively worse month after month, as far as not responding to user needs, doing a hellacious redesign that was retina searingly bad, being incredibly condescending toward customer complaints, subtweeting my co-founder on a podcast, and other delightful things. So, the time came to leave Drip. So, what do I do next? Well, my answer was to go to SendGrid. And SendGrid was pretty good at these things. They are terrific at email deliverability—in other words, getting email, from when I hit send on my system into your inbox, bypassing the spam folder, because presumably, you've opted in to receive this and confirmed that you have opted in—so that wasn't going to be a problem.
And they still are top-of-class for that problem, but I needed something more than that. I didn't want to maintain my own database of who was on the newsletter or not. I didn't want to have to handle all the moving parts of this. So, fortunately, they wound up coming out with a tool called Marketing Campaigns, which is more or less designed for kind of newsletter-ish style things if you squint at it long enough. And I went down that path and it was, to be very honest with you, abysmal.
It was pretty clear that SendGrid was envisioning two different user personas. You had the full-on developer who was going to be talking to them via API for the sending of transactional email, and that's great. Then you had marketing campaign folks who were going to be sending out these newsletter equivalents or mass broadcast campaigns, and there was no API to speak of for these things. It was very poorly done. I'm smack dab between this, where I want to be able to invoke these things via API, but I want to also be able to edit it in a web interface, and I don't want to have to handle all the moving parts myself. So, I sat down and had a long conversation with Mike, my business partner. And well, before I get into what we did, let's stop here.
This episode is sponsored in part by N2WS. You know what you care about? Many things, but never backups. At least until right after you really, really, really needed to care about backups. That's what N2WS does for your AWS account. It allows you to cycle backups through different storage tiers; you can back things up cost-effectively, and safely. For a limited time, N2WS is offering you $100 in AWS credits for setting up their free trial, and I encourage you to give it a shot. To learn more, visit snark.cloud/n2ws. That's snark.cloud/n2ws.
So, we looked at ConvertKit, which does a lot of things right, but there are a few things wrong. There's still no broadcast API, you have to click things to make it go. So, I have an email background, Mike has an engineering background. And we sat there and we've decided we're going to build something ourselves to solve this problem. And we started drawing on a whiteboard in my office. This thing is four feet by six feet, it is bolted to the wall by a professional because I have the good sense to not tear my own wall down, instead hiring someone else to do it for me.
And we spent a couple of hours filling this whiteboard with all of the features we'd want this to have and how we would implement them. It would require multiple things databases because we wanted to have an event system when someone clicked the link to opt themselves out, we wanted to make sure they got opted out of that thing. But did we want them to opt out of everything like the t-shirt announcements that we run? Now, that we have multiple newsletters, we want people able to opt in for the Wednesday, but not the Monday, and vice versa. So, we realized at the end of a few hours of work that A) we had completely filled this enormous whiteboard. And 2. We had effectively built ConvertKit from first principles and fixed a couple of weird bugs along the way, and that was really it.
At which point we looked at each other realized we're being patently ridiculous, threw the whole thing away and became ConvertKit customers, which we remain to this day. There are still a couple of annoying edge case issues that drive us nuts, but by and large, it was the right decision. And what I want to talk about today is that this is a common pattern. And very frequently, the resolution of the story is different, where, “No. We’re going to go ahead and build this thing ourselves.”
Remember, we have a consultancy that fixes AWS bills. And the marketing, such as it is for that, is this podcast, the other podcast, and the newsletter. We're viewed in some ways as a media company, but we're really not. I view what I do, in terms of this sort of thing, as being the marketing function for the consultancy: it gets our name out there. You'll notice that there's no direct call to action here of, “That's why you should call me to fix your AWS bills,” though you should. It's about name recognition so that when someone has a problem one day, we pop to mind when that problem becomes an AWS bill. Our job is not to build an email system from first principles. We are not a product company. Building a tool like that internally should only be done if it adds differentiated value that we can't get anywhere else.
Now sure, if you’re Google or Amazon, you will go ahead and build an email marketing service like that. It makes sense: if you're Amazon, you're going to build Pinpoint and completely biff it for this use case, because it tries to be too many things at once to a market they don't fully understand. But if you aren't either at that scale, or if you're not directly aligned with that as your core business function, then find something that gets you most of the way there, buy it, and move on. Otherwise, I would never have time to write the newsletter, because I'm too busy fixing the system that makes it send to your inboxes. That's an awful place to find myself. I don't want to build SendGrid plus one; I don't want to build a competitor to ConvertKit, because those things are not what I want to spend my time on. I don't find that I can add anything differentiated in that space. And it is such a colossal distraction and waste of effort from the thing that actually does add value, namely me being sarcastic and crappy towards various cloud services here and other places every week.
So, what I'm saying here is, when you're about to build something, make sure that it aligns with the overall strategy your business is undertaking. Remember, every line of code you write is something you're going to have to maintain yourself. Now, I just write a check to ConvertKit, and when things there break, as they tend to occasionally because surprise, that's what computers do, I either, if I'm being aggressive, I open a ticket. If I'm not, I just wait and the problem goes away on its own because that is their core competency; that is what they're focusing on. I don't care who you use for an email service provider. Truly, I don't, I don't have a horse in that race.
If I were starting this newsletter over from scratch, I would almost certainly go with something like Review, or curated.co, or Constant Contact, or Campaign Monitor maybe, or Vertical Response, or a whole bunch of other different companies in this space that solve for this. Don't go ahead and build your own unless you somehow have a take on email newsletters that is going to transform an entire industry and you're going to become a company where that is what you do as a SaaS product. Otherwise, don't do that. You're going to distract yourself and lose focus. And honestly, forget money; forget customers; forget attention. Focus is the number one thing that companies seem to run out of the most.
This has been the Whiteboard Confessional. I am Cloud Economist Corey Quinn. And if you've enjoyed this podcast, please leave a five-star review on Apple Podcasts. Otherwise, please leave a five-star review on Apple Podcasts anyway, and tell me why my choice in email provider is crap.
Thank you for joining us on Whiteboard Confessional. If you have terrifying ideas, please reach out to me on twitter at @quinnypig and let me know what I should talk about next time.
Announcer: This has been a HumblePod production. Stay humble.