This article was originally posted on our blog.
Software Engineers Are a Notoriously Tough Crowd
So why would we try to create a newsletter for them? We just couldn’t help ourselves.
Enter: DevCraft. For a variety of reasons, software engineers are bad users. We know this because developers don’t forward emails like your dad does and they aren’t super connected to mainstream social media. Engineers are elusive.
But we do know a couple key things about them: Developers are continuously learning about the new tools and software in their ever-expanding field, they typically appreciate ridiculous humor, oh, and they like free things.
At Bugfender and Mobile Jazz, we know this because we are engineers. We’re constantly sending these kinds of educational and pragmatic tools (and memes) to each other via Slack. We created DevCraft in an attempt to share the best of these articles, comics, and tools with the world.
Setting Up an MVP
DevCraft began as one of Rúben’s side projects, but we quickly figured out he was onto something good. What began as a simple landing page + signup form started to really gather a subscriber base and it was time to start utilizing these.
We initially thought about using curated.io, but ultimately decided against it as we thought we could set up something similar ourselves, much cheaper. (We ended up spending far more creating our own system, but more on that later.)
With a growing list of intrigued developers, we started mailing out a weekly newsletter using MailChimp. For easy accessibility and SEO purposes, we thought it would be beneficial to have the archives available on our site. We liked having the option to write blogs from time to time, so we decided to install good old WordPress as it’s quick to setup, easy to theme and has a great API.
But reality struck as we realized that producing a high-quality newsletter every week is a huge challenge, and took way more time and money than we ever thought.
Curating good content and writing a summary for every article or tool we shared is very time consuming, especially for a bunch of people who are engineers by trade. To maintain a regular readership, we also knew that we would have to send something out weekly.
We were never short on source material, as we have a steady stream of content coming from the MJ team via Slack. Though we don’t encourage procrastinating, our team members inevitably seem to be a fountain of never-ending links to interesting ideas and inventions.
But creating the damn thing every week was just taking too much time, so it was clear to us that we needed to start automating as much as possible. We wanted more time to figure which of our tests were really working, promote the newsletter, and grow our subscriber base.
Automation, Automation, Automation!
Before we automated DevCraft, we were doing everything ourselves. Manually. Meeting to discuss the content, writing and formatting the content, sourcing and resizing images, preparing the HTML for the blog and email campaign, scheduling tweets etc.
To produce a quality newsletter that people will actually read, we couldn’t cut corners.
But we knew that everything besides actually preparing the content needed to be as lightweight as possible, as that’s the work that doesn’t add much value.
The best decision we made was to start using Google Sheets to compose the newsletter. Given that the content of our newsletter is written in specific sections (title + photo + content + link to read more), we wanted to take advantage of the macros and custom scripts Google Sheets offers. We set up a macro to take our content cells and assemble them into a new cell formatted with Markdown and in-turn, HTML.
Automation is rather addictive for a group of developers. After we “broke the seal” with macros, we wanted to automate it even more, continuing with Google Apps Script. This is a lesser known feature of Google Sheets, similar to what VBA scripting is for Microsoft Excel.
So we went down the rabbit hole to see just how much could be automated. First, we added the Showdown library into Google Sheets to render the Markdown generated by the macros into HTML, so we could preview it:
Next, because the images needed to be resized and uploaded to WordPress, we used the WordPress REST API to add them directly to the media gallery of our site, resize, crop and return a link. This ensured the images lightweight so they wouldn’t slow down our emails and site. We were on the right track.
We used the same API to create and publish the newsletter archives themselves. In addition, we used MailChimp’s API to create new campaigns, adding the generated HTML content to them.
All these functions were accessible with this nifty custom menu we created:
We also started posting more often on our Twitter and Facebook accounts by using Hiplay and Buffer, so there’s always something interesting to read in our feeds.
Figuring Out What (Sorta) Works
By doing one of the things we know how to do best (i.e. scripting custom functions), we freed ourselves up to market, experiment, and test our newsletter. We were able to study our actions and figure out what worked.
To start with, we changed up the newsletter’s structure and type of content. Our subscribers seem to like the custom descriptions below each article or tool we share--as long as they are short and straight to the point to aid skimming. We only saw a soft reaction when we decided to invest less time in the descriptions we wrote about each link. Click through rates dropped and a couple of users unsubscribed but there was no drastic change.
Then we took the most frequently clicked link topic (usually something about remote working) and put it at the end of the newsletter. It turns out that this link was still the most clicked, so we learned that our subscribers do read through the entire newsletter to find the gems.
Like online dating, what seems to work is just persistently putting ourselves out there. Real interactions and networking with people on Twitter, Facebook, Reddit, Hacker News, & Slack channels seem to work. We’re still on the hunt to hone our inbound marketing for new readers, though we do grow our subscriber base slightly every time we find a new channel to post on.
Posting regularly reminds people that we are here. And maybe that we’re kinda cool.
Where We Are Now
When we started DevCraft we had no idea on the journey it would take us and the lessons we’d learn. All day every day we share links in Slack and we thought it would be pretty easy to share them with the world.
There are several services available which offer newsletters and subscriber management in easy packages, but we wanted to create an MVP with minimal overhead. Little did we know how much time we’d invest ourselves, often wondering if we should have just created a plain text newsletter, or used one of the available services.
There are shortcuts that we could have taken in both design/presentation and content, but we compete with thousands of newsletters out there. We still want DevCraft to be reflective of the dynamic community of developers and designers at Bugfender and Mobile Jazz.
Thanks to the automation we’ve set up, DevCraft has become sustainable, and now requires an hour or two for each edition. That being said, we’re still trying to figure out it’s path and purpose. People are being bombarded with news and entertainment these days, so having another newsletter (even if it’s high-quality) might not be what people seek. Whether DevCraft fills an actual need is still questionable and something that we need to figure out in due time.
That being said, our subscriber has grown steadily and we have a loyal fanbase with very few unsubscribers. Recently, an agency reached out to us to place advertisements on our next issues, so it’s gaining traction and steadily becoming a viable business in its own right.
If you’d like read about the things we share and follow our journey, sign up today!
This article was originally posted on our blog.
Top comments (0)