Lessons Learned from Creating Content on 2 Sites Instead of 1
Learn why I chose to write about Docker on diveintodocker.com, then decided against it, and moved everything to this site.
About 4 months ago I wrote about how I was going to fork this blog and only write about Docker related content on diveintodocker.com.
At the time it sounded like a great plan. I would put up a new site that was all about Docker. It would have a ton of free articles and have a couple of pages that also talked about and described my latest Dive Into Docker course, along with any other Docker courses I put out.
You could say I was creating a brand. I envisioned having multiple Docker courses under that brand along with having hundreds of articles in due time.
So that’s what I did. I created the site and it had everything you would expect. A home page, about page, an email newsletter to receive Docker tips, 27 articles (I posted 2 articles a week) and a dedicated page to describe the course itself.
For example, here’s what diveintodocker.com looked like before I changed it:
# Starting From Ground 0 Is Really Tough
If you’ve ever tried to start a blog or launch a product then you know how hard it is to build an audience and gain any form of traction (even the slightest bit).
…and here I was, attempting to grow a second audience.
At this point my personal site has been around for 2 years and while it doesn’t have a massive amount of traction, it’s a lot better than a fresh domain.
Even with getting thousands of social shares on those Docker articles and getting tens of thousands of visitors it didn’t really move the needle on getting organic traffic after a few months.
At the same time I noticed this site was suffering a bit in terms of organic traffic because I wasn’t posting nearly as often as I used to. That’s because I was focusing 95% of my writing efforts into diveintodocker.com.
It takes a lot of effort to write regularly, and I can’t write more because I also need to do freelance gigs (for primary income) and create new courses. I’m not spread razor thin but let’s just say I don’t have an off switch and an extra 4 hours a week to write 1 more article isn’t in my time budget.
# Finding Flaws and Fixing Them Is Making Progress
That got me to thinking about a lot of things. Not only is this strategy unsustainable in the long term, but it’s also flawed.
It’s flawed because while I love Docker, I don’t want to be married to it. I write about and create courses on it now because it drastically improved my work flow for developing, testing and deploying web applications and I want to share what I’ve learned with others.
But in the end, I consider myself to be a pragmatic programmer. If something better comes along next year, or I move on from Docker (really unlikely but who knows) then I don’t want to lose all of that effort from building up diveintodocker.com.
Also, if you’re curious, I have plans for AT LEAST 2 more Docker courses and have over 100 articles I want to write and publish on the topic of Docker. Heck, I even recently created a free intro to Docker email course (you can sign up by going to the bottom of any Docker related blog post, such as this one). Long story short, I’m still super excited about (and use) Docker.
I just want to make sure from a business perspective that I have the flexibility to move from technology to technology without having to start from ground 0 in terms of audience growth.
# Running a Self Diagnostic, Outcome? Operational
After realizing the path I was going on, I took half a day and ran a self diagnostic to make sure I’m still doing what I want to be doing.
I highly recommend you do this on a semi-regular basis. That’s just a nerdy way of testing to make sure you’re reaching your goals and are happy with your life choices.
The results were good. I still want to continue this adventure of creating courses, blogging and doing side gigs in the form of freelance consulting.
During this self evaluation session I also learned that I want the freedom to create content on anything that interests me without having to compromise my other courses.
So for the last few months I’ve been blogging on the Docker site, creating a new course, and completely redesigning this site for the upcoming site merge (which already happened).
# Fool Me Once, Shame on You, Fool Me Twice…
For instance, I just launched that new course I was working on, which is HTTPS with Let’s Encrypt. It goes over everything needed to host and secure any website (or web app).
Sure, it’s on its own domain name, but that is much different. It doesn’t have a surrounding site. It’s just the landing page to learn about and get the course. That’s exactly what the new Dive Into Docker site is now too.
If I went down the path of creating a full blown site with each course, then I would end up with a bunch of articles on that site instead of this one.
That means eventually I’m going to end up with hundreds of articles spread across multiple domains, each starting from ground 0 for rankings. Essentially I would be abstracting away this entire site and it would fade away because all of my posts would be on different domains.
There’s an important programming lesson in all of this, and that’s related to trying to write “perfect” code from the start of a project. You just can’t do it. You have to be in the trenches writing code, and then when you see a pattern, problem or ugliness you swoop in and adjust it based on experience.
That is exactly what happened here. There’s no way I could have known this without first experiencing the problem first hand. It wasn’t until the 2nd time that I detected a pattern and thought “hmm, this isn’t going to work”.
# What Is Your Niche and Are You Your Own Brand?
They say “you need to niche down to be successful”, and that’s totally true. If I were releasing a product or a SAAS application I would niche down pretty deeply.
For example a scheduling app for a hair salon is going to do a lot better than trying to make a scheduling app for everyone.
Likewise, Dive Into Docker is a course focused on learning and applying Docker. It doesn’t concentrate on things like deploying or CI. So while my courses are niched down, that doesn’t necessarily mean I need to micro-niche down the entire blog. It just needs to be semi-related.
It took me a while to realize that for what I’m doing, I am my own brand.
For other businesses (such as a SAAS app), that might not be the case. If I created that hypothetical hair salon scheduling app, then I would certainly write articles on that domain, but when you create developer focused courses and articles, it probably makes sense to have all of that under the same roof.
Do I know for sure if this is a good idea? Nope, but the only way you’ll learn is by testing things out because there are no guaranteed “right” answers. With that said, I’m sure there are people right now who are successful doing it 5 different ways.
Let me know if you’ve dealt with this situation. I would love to hear your story.