When we initially acquired MasterWP from Alex and Ben, we needed to move the newsletter infrastructure somewhere quick. We knew we needed to get into the editorial flow fast with tools that would quickly enable collaboration between multiple authors and editors. We initially went with Substack over WordPress, and as you can imagine, that lasted about a week. Here’s the story of how MasterWP went from WordPress to Substack to WordPress.
Internal reactions to Substack
From the outset, internal discussions around the choice of Substack were… sensitive to say the least. Topical issues of free speech, content moderation, “cancel culture”, and platforms-vs-publishers were certainly swirling around our heads. At the end of the day, there are no right answers to any of these issues, because this is all uncharted territory. We decided to judge Substack on the merits of its technology, not its user base or place in the cultural conversation.
One of the first changes we wanted to make was to separate the content from the email-based newsletter itself. We basically wanted to pull out the individual articles and build more of a blog that would feed the newsletter. We wanted individual pieces to have static URLs so they could feed discussion (and boy have they) and engage with the community. Substack did allow that, and they bundled the newsletter-sending service as well.
At first it worked pretty well, but Substack is really meant to get you off the ground, not for newsletters showing up with massive email lists. From the moment we began importing subscribers, the technical limitations started stacking up, and we started evaluating the case for migrating to WordPress.
Accessibility
Substack has decent accessibility baked in, but there were a few things outside of our control. Some of the color contrast ratios were a little lower than we’d like. By using our custom Understrap child theme (based on the Bootstrap design framework), we were able to match the general aesthetic but also swap out a few SASS variables to make sure that colors were legible across the board.
Similarly, Substack played it a little loose with HTML, specifically heading elements, often using them decoratively rather than semantically, so now we have full control over the page heirarchy. For us, accessibility is a default part of WordPress web development and something we’re always trying to improve.
PageSpeed and SEO
We’re big fans of decreasing page size and increasing page speed. It’s great for SEO, but it’s also great for decreasing bandwidth usage. This helps mobile users with stricter data limits and reduces your site’s carbon footprint. With Substack, we had absolutely no control over the code, so we couldn’t do any of our basic optimizations. We were failing on all aspects of our Core Web Vitals and the site felt sluggish. With our own codebase and a few basic plugins (hello Autoptimize), we’re seeing green.
On top of that, we’re using Yoast, Google Analytics, and a few other tools to monitor our search engine presence and overall performance of the site. While we believe that content is king, it doesn’t hurt to make your content as discoverable as possible.
Test driving the block editor
Substack actually has a pretty nice content editor. You can tell it owes a lot to Medium, which I would consider its spiritual predecessor. To use WordPress terms, I would describe Substack’s editor as somewhere between ‘Gutenberg-lite’ and ‘Classic Editor-plus’. It’s what the current block editor would feel like if you stripped away about 80% of its functionality, mainly the myriad design options that are now bundled into Gutenberg. It’s a block-style editor without any sidebars, panels, or meta boxes (my personal dream). But this is a WordPress publication, so it makes sense for us to write all of our articles inside the WordPress block editor.
As someone who codes for WordPress sites 40 hours a week, it feels odd saying this, but I’d forgotten how nice WordPress is for a content-centric website like a newsletter or magazine. Everything from auto-saving post drafts to creating contributor accounts is a breeze. Using WordPress as typical “users” rather than a developers has been a nice change of pace, and it’s also forcing us all to spend a lot more time in the block editor than the code editor.
As an aside, I would love to see a ‘Gutenberg-lite’ option (or plugin) that could tame the Guten-beast while writing posts. As the post editor turns into more of a page builder, unnecessary features and cryptic icons tend to crowd out the post writing experience. When I’m building a website and populating pages, I need to disable fullscreen Gutenberg so that I can have quick access to the admin bar and sidebar. When writing a post, however, fullscreen mode is wonderful. It’d be great to be able to disable even more of the unnecessary features when writing a post.
One rough edge we hit was our attempt to build our homepage in the block editor. We were interested in mimicking the three-column Substack layout where column 2 is semantically first (and appears first when stacked on mobile), column 1 comes second, followed by column 3. We built a version of the homepage using the Query block to pull in various amounts of posts, which was pretty great (even if it did push me to rant on Twitter about it). The columns block, however, was a non-starter. Not only was it impossible to get the ordering we wanted, but the lack of controls over how they handled smaller screen sizes made for some terrible tablet layouts. It was simply not shippable. Needless to say, we went with some quick custom code in our child theme and our favorite plugin, Advanced Custom Fields, to round out the home page.
Future Customization
One of the major drawbacks of Substack (and Medium) is the sameness of everything. The actual newsletter that Substack sends out offers almost no branding. MasterWP was looking like every other Substack newsletter in your inbox. As a long-time MasterWP reader, I missed the color palette, the warmth and friendliness it provided. I think there’s also some bigger philosophical issues about sameness on the internet. The fact that a Facebook post from a mainstream newspaper looks the exact same as a post from some random teenagers is probably not good. We need more context and more personality online. Or maybe I just miss my old Geocities sites. Anyway, this was just one of many examples of why we want to control our own code.
Owning your own code
We have big plans for MasterWP, and we wanted to be able to have full control over what happens on our site. Heck, that’s why our agency sells WordPress websites in the first place. We don’t want to rely on any other SaaS platforms or frameworks when we don’t have to.
This is the heart of WordPress, the reason you modify a child theme, pick WooCommerce over Shopify, or run with a codebase that’s almost twenty years old instead of the latest SaaS offering. There’s plenty that we could learn from competitors like Substack – for example, how quick and painless the onboarding process can be for new users – but overall WordPress is where you build something if you have big plans for the future.
