In this post, I’m going to teach you how to ship your side projects.

How to turn them into a potential business. Keyword: potential. There are no promises here.

I can’t turn water into wine, people. 😉

Now, back to shipping side projects …

It’s easy once you realize how difficult it is.

Yeah, that sounds bass-ackwards. 🤔

I’m serious, though. It is easy once you see that the difficult thing is looking you in the mirror.

Yes, you’re getting in your own way, and you don’t even know it.

I’ve been shipping side projects for over 20 years. Some did well, most failed. It’s how it goes. You have to roll with the punches here.

What is a side project?

A side project could be something as simple as:

• A weekly newsletter (like this one)
• A weekly blog post
• A mobile app you wrote
• A web app you wrote
• A tool you created
• An open-source project you created
• A script you wrote
• A framework you developed
• A physical book you wrote
• An ebook you wrote
• A video
• A tutorial
• …

You get it. A side project could be anything that you want.

For the sake of this post, I’m going to stick with a software product, though.

It could be a mobile app or web app, or even a desktop tool.

Nuff fluff: Let’s get to it.

Tip 1: Realize That You’re Going to Fail

The sooner you realize that your chances of success are low, the faster you can ship it.

You’re thinking: “What? Huh?”

Once you embrace this thought … you have nothing to lose.

If you don’t ship your side-project, you’re in no better spot than you are now. The only difference is that you have a bunch of dead code in a folder on your drive somewhere (your project).

If it sits on your drive, it’s worth nothing.

Yeah, blah blah blah, I know … you learned something from it, so it’s not entirely useless. I get it …

That’s not why you’re still reading this post, though.

You want to learn how to ship it. Right? Right.

Embrace the truth that most likely, this project will fail, but you don’t know for certain until you try.

I want you to know that I’m not trying to be a downer here. I’m trying to help you realize that this is the reality of shipping side projects.

So… ship it already.

Tip 2: Forget about monetizing it for now

You most likely fret over this like crazy.

I know I have more times than I’d like to admit. Hell, I still do it.

You get stuck in an analysis paralysis loop of the following questions:

• “How can I make money off of this?”
• “Will the user pay for it?”
• “Should this be a one-time payment or monthly subscription?”
• “Can I monetize this with ads?”
• “Can I find enough 43-year-old moms who drive Ford minivans built between the years of 2008-2012 that will buy my custom rear-facing baby dashcam mount?”

First of all. Forget ads. That ship has sailed.

Storytime – back in 2008, I had 4.5 million app installs of one of my side project apps, and I was making $60-$100 a day. Things aren’t like that anymore.

Yes, that’s good money for a side project, but that didn’t last long. That got shut down soon after the ad rates dropped.

Ok, so ads are out … unless you really do like living off of Ramen from the dollar store. So … what about the other options?

If you don’t have a solid plan out of the gate, ignore pricing right now and ship it.

This concept cemented one day after I heard Josh Pigford talk about this on one of his podcasts.

The TLDR is this – if you have a side project – ship it and get it out there. If it’s popular, then figure out how to monetize it. There will often be a clear path on how to monetize. If not, then run it for a while to see if you can identify a monetization method or shut it down.

In other words, if you’re having a hard time deciding how to monetize your side project – don’t. Ship it and see if the market likes it first. If there is a positive response, then think about it and adjust, but don’t let it distract you from shipping.

Tip 3: Ship it before its ready

You had to know this one was coming.

This is age-old advice that I still adhere to.

As the saying goes, “If you’re not embarrassed by what you shipped, you shipped too late.“

Why would you do this?

To see if there is any interest in your project.

Consider these scenarios:

• A) You ship early and learn that the market did not respond to your project. No one uses it. Ok, no harm – no foul. You cut your losses and move on.
• B) You ship early and find out people like it. You accept their feedback and improve the product. Awesome.
• C) You don’t ship until it’s perfect. You ship it and realize that your assumptions about the market were wrong. No one uses it, or no one understands it because of many incorrect assumptions made. You realize you wasted a tremendous amount of time.

Most everyone defaults to scenario C. They wait until it’s perfect to ship something.

Stop it. Ship it now.

Your terms and conditions weren’t done? Ship it.

Your privacy policy isn’t done yet? Ship it.

Your monthly billing isn’t done yet? Ship it.

Wait, what? Billing isn’t done … and ship it?

Yes. Ship it.

There are many companies that have shipped without functioning billing software. They wanted to get it into the public quick. These companies had another 4 weeks to wrap up the billing stuff while the users gave other valuable feedback.

Contact page isn’t done? No problem. Use a form like TypeForm. Ship it.

You get the point. Ship it when you’re still somewhat embarrassed by it, and then refine it.

Tip 4: Don’t attach your emotions to your project

I cant’ tell you how many times I’ve done this.

This is when your project is YOU. You and your project are one. It’s like a child to you.

Bad mistake.

You’re setting yourself up for some upset.

Ask me how I know.

When you attach your emotions to your project, you will make emotional decisions. Emotional decisions are usually not great ones. Furthermore, they’re often slow.

This could be anything from pricing decisions to feature decisions to support responses. Anything for that matter.

When (not if) users criticize your project, it will sting and often feel like a direct attack. That’s not their intention, but if an emotion is at play, it can feel like an attack.

This makes it hard for you to detach and do the work necessary to improve your project once it’s shipped.

Tip 5: Treat it as a learning experience

This is tip #1’s cousin.

You already know that your project has a high chance of failure. You’re not upset about it because you’re putting it out there to see if it gets any traction.

Another way to look at this is that what you’re doing now is a learning experience.

I recently did this with a project called “Gifstagram.” It was the easiest way to convert any gif into a loop-able MP4 file that would be post-able on Instagram.

I didn’t have any clue if anyone would pay a cent for it, but I knew that I used it and that it could be of use to others. I also wanted to know how to use Amazon AWS Lambda functions, and this was a perfect opportunity to learn how to use them. So that’s what I did … I created the entire web app on AWS with AWS Lambda, SES, API Gateway, Aurora, and S3.

I treated it as a learning experience to say I was able to ship a project that used all these technologies.

Let me tell you something … WOW, I learned a ton on that small project.

I recently shut that project down. It was not getting used that much, and there was no clear path to monetization.

The learning opportunity was worth its weight in gold, though. Treat your side projects the same way and you always stand to gain something from it.

Tip 6: Realize whether your side project is a vitamin, painkiller, or candy

Twizzler? Runts? Skittles? I used to eat the crap out of those.

My dentist loved me because I paid him so much money.

Ok, I digress…

Your product is “Candy” if … it’s something a user would like to have and makes their life more enjoyable, but it’s not necessary.

Your product is a “Vitamin” if … it’s something that the user should use but can do without if need be.

Your product is a “Pain Killer” if … it’s something that the user wants and needs right now to solve a very immediate problem.

Which category do you think you want your product to be in?

Pain killer.

Why?

Think of it this way: You’ve got a toothache.

What do you want? Candy? A vitamin? or a Pain Killer?

You want the pain killer.

You want the problem to go away.

If your product makes a problem go away – it’s a pain killer.

If your product makes their problem less as bad, it’s a vitamin.

If your product makes their life more joyful in some way, it’s candy.

Why are these all-important?

It’s important because it will help you plan on how to sustain the project over the long term. Will it be something you can monetize, or is this a goodwill project? This helps frame the project and its potential trajectory in the market.

Think of it this way – pain killers do better than vitamins, and vitamins do better than candy. They can all work, but where do you want to spend your time? Personally, I prefer to work on painkillers.

Tip 7: Have an exit plan

In the previous tips, you learned that you can use shipping a side project as a learning experience. This is great, but when do you pull the plug on your shipped project? Or should you?

To know that, you need an exit plan.

• This could be monetizing your project by a certain date.
• It could be getting some maintainers to help you with your open source project by a certain date.
• This could be shutting it down if certain metrics are not met by a certain date.
• It could be selling your side project if you lose interest in it by a certain date.

Notice everything is date-oriented. Nothing should be perpetual. If it is, it will take up mental cycles in the background of your head. This will eat away at your personal processing power for other projects that you have.

If you plan on selling it, you can sell on an app marketplace or website marketplace. No, you’re not going to get 15x of your time you put into it. You might get a couple thousand, or if you have a lot of users but no monetization, you might get more. Don’t expect to get rich, though. See it as a nice bonus and a responsibility you no longer have to tend to.

It’s important to know that you don’t have to love your side project forever. You will outgrow it.

If you get tired of your side project, have a plan for what to do with it. Shut it down. Sell it. Deprecate it if it’s an open-source library. Do something, but don’t let it sit around. It will take up precious mental cycles.

The Final Word

Ship it early. Get feedback quickly. Don’t wait for it to be perfect. It never will be.

PS: By the way, using this exact method I recently re-launched Android Jobs (a Job board for Android professionals). It’s not perfect. In fact, there’s a bunch of stuff that’s simply NOT done yet on it. You know what though, many companies are using it already. Companies like Instacart, Capital One, Bumble, Snapchat, Pandora, Twilio, Vizio … the list can go on and on. Long story short – your product doesn’t have to be perfect to provide value. Just ship it.

Photo by NASA on Unsplash

I’m going to show what the difference (and similarities are) between freelancing and consulting are.

If you look online you’ll find a plethora of different advice on what they are and are not.

Unfortunately, most of these articles are written by people who have very little experience in either one of these fields. I’ve had experience in both, so I’m going to shed some light on it for you.

So …What’s is the difference between freelancing and consulting?

Drum roll …

They’re basically the same thing.

… with some small differences that I’ll talk about below …

There will be many people who disagree with me, but that’s ok, let me explain why I think there’s not much difference.

Take a look at this graphic …

In this graphic, I’m illustrating that there’s about a 50% overlap in consulting and freelancing. This is all based on my 20+ years of experience in freelancing and consulting.

Freelancing

When you freelance you often will be given a project or a task and you’ll get it done. That’s it.

The task might be to create an app, or a website or a graphic, etc. In the “25% Unique Freelancing” section above these would be jobs that you’d find on sites like Fiverr or a quick job on UpWork that has very specific and defined guidelines (and usually a short time frame).

Examples of freelancing gigs would be …

– Create a script that scrapes example.com and if it finds the text “chicken wings” (hey, what can I say … I’m hungry) then it needs to send an email to jb@example.com
– Create a logo with a bird holding a kettlebell
– Set up a WordPress site

These are simple and well-defined minute tasks that can take a few hours to a day or two. They’re usually very small and often don’t end up in longer-term work (though they can). As a freelancer, you typically get in, get it done, and move on.

Consulting

When you strictly consult, you’re often brought on to provide advice for a given system, architecture, and systems installation and configuration.

You’re using your expertise in the industry to help a company solve a particular problem. This advice often turns into a statement of work in which you will then be the one implementing the solution for the company. Often, consultants advise companies of the best solution for their given problem.

For example, if a company knows there is a problem with its data management procedures it might bring in a consultant who deals with big data implementations and optimizations to help them figure out the best solution for their problem.

Consulting problems are often vast and the consultant needs to understand the business, what the business needs are what the current problems are. They have to get into the business to figure this stuff out. After they come to their conclusions they will advise the company on what to do. At that point, the company will often decide to accept the advice and often hire the consultant to implement it, or look for another opinion/refine it with the consultant until a suitable solution is found. This is 25% of the unique consulting.

The Overlap

Note how I said that consultants can and often will implement the solutions? This is where the overlap with freelancing comes in.

On a similar note … oftentimes, freelancers will be with the same client for several months (even years) helping the client implement various solutions. This is where the freelancer overlaps with the consultant.

The work of implementing solutions is the 50% overlap you’ll see in consulting and freelancing. It’s where the work is done.

The main difference is the origin of the work.

Small task? Freelancing
Advice and Guidance? Consulting

Implementation: Freelancing and Consulting

Who typically does freelancing?
Freelancers can be found almost anywhere. However, for purposes of this article, you’ll typically find programmers, graphic designers, bookkeepers, copywriters, translators, and more will be who represent freelancers the most.

Who typically does consulting?
When you look up consulting online, you’ll often find that consulting is usually referenced in the financial, management, and planning areas of business. You might see roles in areas such as financial planning, business management, medical implementations, law, etc. However, there are also technical consultants as well that help with systems integrations and implementations.

You might be wondering now …

Are you a freelancer or consultant?

Does it matter?

That’s a good question. Yes, it does matter, based upon your client.

Ultimately, I think this is something that someone has to answer for themselves, but here’s my heuristic:

If I’m being hired for advice on systems, what systems to build and how to implement them, and more: That’s consulting.

If I’m being hired to implement an app, a website, a script, etc: That’s freelancing.

There are times when they can overlap with one client. I’ve had instances where I was hired as a consultant for a particular project. That project was a success and completed, yet the client wanted to keep me on for additional work that they had, and that turned into more of a full-time freelancing project that consisted of a bunch of smaller tasks. However, an occasional project would show up where they’d need advice and implementation support and it would ebb and flow back to a consulting project.

Furthermore, I’ll often be consulting for a client for a long period (6 months to a year or more) and during that time I’ll pick up a small freelancing project that might take me two days to a week to complete. I’ll do that on the weekends and off time to make some extra money.

In other words, you can do both, at the same time.

What should you call yourself?

This is a big one for a lot of people.

The word “Consultant” carries more professional clout than “Freelancer” does.

The term ”Freelancer” feels more “fly by night” (without reputation).

There’s nothing wrong with either term, I’m just explaining how the industry sees the words. This typically only matters when you’re trying to garner the attention of a larger client though,

Please note … the term “Consultant” comes with some additional requirements: You should be an expert in your field for you to be calling yourself a consultant.

Assume that you’re fresh out of school. You’ve never completed a project with XYZ technology. At this point, you should not call yourself a consultant on XYZ technology as you have no experience with it. However, you can still be a freelancer with it as you’re probably confident enough that you can figure it out and help the client project succeed.

If you’re talking to a larger client and you’re an expert in the technology or field then I recommend that you go with “Consultant”. It has more of a professional ring to it.

That about covers it.

For the most part, they’re the same thing, it just depends on the angle in which the client engagement starts and what they’re looking for. After that, the waters get a little muddy as implementation work is … implementation work – regardless of how you look at it.

Photo by Faizur Rehman on Unsplash

He said “Ok, we don’t need that feature anymore, you can delete it.”

I had just built the feature two months ago. I spent nearly 2 months building it. I had poured all of my heart into building this feature. It was a masterpiece.

Or so I thought …​

Wait … now I’m supposed to delete it? What?

Why?

To be honest, I didn’t know at the time.

.. but I do know one thing though, it pissed me off. It felt like a gut punch.

This happened around 2011 when I was working for Groupon.

After thinking about it for an hour or so I decided to approach the product owner who told me to delete the feature and ask him why. It went something like this:

“Why would we delete this perfectly good feature? The feature great, there are no bugs, it was really technically challenging and I implemented in a way that was very elegant. It seems silly to throw it away, we just shipped it less than a month ago. Why would we do that?”

The product manager looked at me, lifted his chin and then dropped it down towards his chest like he understood the problem, slowly nodding in partial agreement, lips tightly pressed together …

He then explained to me that the feature that I had built was a new experiment that Groupon wanted to try. We tried, it, the customers did not respond to it as well as another flow.

In short, we had two features that did the same thing and mine was not the best for the business.

It was then I realized that I was emotionally attached to my work, and I should not have been.​

How did we know my feature didn’t do well?

We A/B tested the two features against each other.

Again, my feature didn’t do that well in regards to conversions vs a similar feature that did the same thing.​

Not because my code was bad.

Not because my code was wrong.

Not because anything I had done.

We thought the customers would prefer this new experience.

We were wrong.​

Therefore, my feature was no longer needed.

I eventually deleted the code. However, I do keep a repository of code snippets around (I use Quiver) just in case I want to do something like that again. In the end though, the code was deleted from the app.

​

Recognizing that you are not your creations …

Once I understood that I was too emotionally attached to my creation it ended up being a defining moment of my career.

It was then I understood that I should remove emotional attachment to the things I create.

In this case, the code was a tool.

We use tools to build (and repair) things.

The thing I built did not perform its job. It doesn’t mean it wasn’t good, it just wasn’t as profitable as another very similar thing we had already built.

In software, things change. They have to.​

We make assumptions about what we think the users will want, but the only real way to know for sure is to test them. We do that with A/B testing frameworks, watching conversions, funnel drop off rates, watching revenue, sign ups, etc. Its all metrics.​

Remember … “What Gets Measured, Gets Managed” ….

A Mindset Shift

One thing that helped me move on from this emotional attachment is to realize everything we’re creating (especially in software) is temporary. Sure, you might create a cabinet or some art or something in the physical world, but even that is temporary.​

If, for example, you are fond of a specific ceramic cup, remind yourself that it is only ceramic cups in general of which you are fond. Then, if it breaks, you will not be disturbed. – Epictetus

In other words, the thing we’re grown an attachment to might can be gone at any second. If we assume its temporary, then we enjoy it right now, for what it is.

The same thing is happening with my code.

The same thing can happen to your creation, your art, your design, your writing, etc. It can leave or vanish at any time.

Very similarly, the same thing happened when Viktor Frankl had his manuscript taken from him when he entered the Auschwitz concentration camp in World War II.

It was his life work … all taken from him. He let go of that attachment, focused on what was in front of him, and then made that his purpose at the time. Later, after he was free, he ended up re-writing the book which eventually became “A Mans Search for Meaning” (I highly recommend reading it).

Where am I going with this?

Now, when I create something I don’t get attached to it.

In fact, I find solace in deleting more that I create.​

Why do I find enjoyment in deleting over creating?

Because it means that I’m simplifying.

Think about it …

Remember the last time you cleaned your desk?

Remember how good that felt? Look at all the open desk space in front of you.

You probably felt like you could breath, you could stretch out. Nothing was encumbering you anymore. No more distractions. No more “stuff” everywhere.

What you did was delete the stuff from your desk. Sure, you may have just put it back where it belonged, organized, etc, but you get the point.

Creation can be and should be very enthralling and captivating for you. In fact, I find great joy in creating.

However, when I’m done I let it go.

I’m happy about what I created, but then done with it and onto the next thing.​

It is what it is.​

Once you can let go of your emotional attachments to your creations that you’ll find you’re free of anything that happens to them … and that is a freeing feeling unlike any other.

​

“If you are distressed by anything external, the pain is not due to the thing itself, but to your estimate of it; and this you have the power to revoke at any moment.” ― Marcus Aurelius, Meditations

 

Photo by Markus Spiske on Unsplash

In a very recent email I wrote about how you need to have a blog.

The question that pops up next is usually …

What blog platform should I use? Medium? WordPress? Gatsby? Jekyll? Or something else?

This is a HUGELY important question that needs a bit of thought put into it … but first things first …

You Need to Focus on Writing

Before I get into comparing the vast array of options that you have out there I want to state that if your goal is to start bogging then ….

YOU SHOULD NOT BE FOCUSING ON BUILDING SOFTWARE TO RUN A BLOG

In other words, if you’re a software engineer (and some of you are) you should not get consumed with “building my blog” with some latest and greatest technology that you can learn along the way.

If your goal is to write ….

Then put your ego away and start writing.

If your goal is to learn a new technology then stop reading this and go learn a new technology.

Far too often I see software folks lose all of their time “building” something like a blog with technology X, Y and Z and then never ship a blog post because they were too busy optimizing CSS, HTML, JavaScript, deployment methods with integrated CI/CD pipelines.

All of that is a waste of time if your goal is to start writing a blog.

So focus on writing – not on building a blog engine.

Choosing a Platform

Choosing a platform can turn into a serious case of analysis paralysis. I hope to solve that for you today by comparing some of the top platforms and what they have to offer (on the good and bad front).

At this time I’m going to compare the following blog systems that you can use.

• Medium
• WordPress
• Ghost
• Static Sites (Jekyll, Gatsby, etc)

I’m not going to cover SquareSpace or Wix or Blogger or any of those because I don’t feel they’re in the top three choices for the folks that read this blog (mainly software engineers and entrepreneurs).

Medium

Everyone loves Medium because it’s drop dead simple to get started with blogging. You can sign up for a free account and then start writing in their editor in less than a minute.

The tooling that they have is top notch. The editor is gorgeous and they make it really simple to craft your content quickly. They also have a very powerful recommendation engine for readers. Meaning that if you have a blog on Dog Grooming and you write about Dog Shampoos then another reader who is reading another dog blog about walking dogs (on Medium) then there is a very high chance that Medium will recommend your article to them to read next. Again this is only for other blogs on Medium. Medium will not recommend other sites to visit for you to find similar content. Just doesn’t work way. The power of their network recommendation engines for exposing your content to others is fantastic.

However, that’s where the great news comes to a close. Medium has more downfalls than positives in my opinion:

• You have no ability to customize your blog.
• You CANNOT ADD features like:
  • Custom Domains
  • Email sign up forms
  • Payment forms
  • Customized landing pages
  • Contact pages
  • Custom integrations
  • Etc

I could write a small book about things I don’t like about Medium.

Lastly, and most importantly, if your content is on Medium –

You are the product.

Meaning that Medium is using YOU as their product to sell other services.

Medium is using YOUR content as a way to recommend other things to other viewers.

Medium is using your content as a place for them to throw up their pay wall to get folks to convert to paid members.

They own everything on the site and can do that they want with it (to an extent of course).

Lastly, one of the things that REALLY bugs me about Medium is that you cannot have your own domain (they use allow this, but not anymore). That means your blog will be medium.com/@yourusername

So … thats kind of lame.

Thats like having a business and then printing your AOL email address on your business card.

In other words – it looks like shit it makes you and your brand look half-assed.

That said, Medium is simply a “easy to get going” blog. Game over.

PROS

• Super simple to get started
• Gorgeous editor
• Great Recommendation Engine

CONS

• You are their product
• No custom domains, have to use the ugly medium.com/@yourusername format
• No ability to provide landing pages, payments, custom pages, forms, opt-in, etc
• Locked into their platform
• Integrations are poor

WordPress

WordPress is the 800 pound gorilla in the blogging world (and internet in general). It has been reported that WordPress powers over 1/3 of the internet.

Thats wild. That’s a lot of sites. Apparently WordPress is doing something right.

To get set up with WordPress, you have a couple of options:

1. Host on WordPress.com (they manage it)
2. Self host or managed hosting.

Hosting on WordPress.com makes it easy to get going, but you’re limited because WordPress.com restricts certain plugins from being installed or utilized and there are a few other restrictions. Therefore I’m going to focus on the self-hosted or managed hosting solution. I’ll provide some links for self hosting and and managed solutions below. Sure, you’ll pay a few bucks, but it’s worth its weight in gold.

WordPress is very powerful. You can build a blog to a full blow website using WordPress. In this instance you will be building a blog.

You can use one of the built in themes or you can search for free themes on the internet (you can also search for premium themes if you don’t mind spending a few bucks). I recommend searching for “WordPress Themes” or “Free WordPress Themes” or “https://www.google.com/search?q=premium+wordpress+themes” if you’re searching online.

One of the best things about WordPress is the powerful plugin ecosystem. There are hundreds of thousands of plugins for WordPress. If you can think of it, its very possible a plugin has been created for WordPress. Plugins allow you to quickly add new features to your blog/site without any additional coding.

With a WordPress plugin you’ll be able to easily add email newsletter option support by adding of any number of email plugins that will allow you to do that. (You may need a email list provider already, such as ConvertKit, MailChimp, etc) but the plugins will be there for you to easily add it to the side bar or bottom/top of your site.

You can create custom pages to house custom content that is perhaps not a blog post, but something like a landing page where you decide you sell a product. Speaking of selling things, you can sell products on WordPress if you use one of the premium plugins like WooCommerce or Easy Digital Downloads.

If you think about doing something down the line, most likely it can already be done with WordPress.

Writing in WordPress is drop dead simple too. You create a new post, give it a title and write your blog post as you normally would. Add images, audio, video, etc all via the online editor that is built into WordPress. Hit publish and you’re live.

Hosting WordPress

I recommend using managed solution to handle your WordPress installation. I’ve tried running my own servers and then moved over to managed hosting years ago and I highly recommend it.

I recommend using a hosted solution such as:

• WpEngine
• FlyWheel

What about GoDaddy? Meh.

GoDaddy overloads their servers with other sites which can be a real problem when your site needs to be responsive. WpEngine and FlyWheel have great response times and have fast servers and don’t overload you with other folks. If you have a problem with anything you can reach out to them and they’ll help you.

I’ve even had WpEngine representatives write some code for me to fix a particular image problem I had with their CDN – which brings up a good point. All of their images are stored on a CDN and delivered globally – making your site load that much faster.

Lastly, since you’ll be running your own blog you can have your own custom domain.

PROS

• Simple to setup with a managed host
• A huge plugin ecosystem
• Very customizable
• Good Editor
• Supports Custom Domains

CONS

• You have to pay $$ to host it
• It can get slow if you over load your site with plugins
• Often targeted by hackers because of how popular it is (if you stay with a managed host, like WpEngine they do a great job of keeping you up to date with security releases.)

Ghost

Ghost is another open source platform that is similar to WordPress but built on completely different technology. One of the biggest selling points of Ghost is that it’s fast.

The editor is simple and is very easy to use and you’ll find yourself creating some great looking pages quickly.

Ghost also offers a set of plugins, but it does not match the breadth of WordPress and that’s a downfall.

Hosting Ghost

Installation is where you’ll get stuck because you either need to install it yourself or host it. I’ll focus on hosting it.

At this point I’d only feel comfortable hosting on Ghost’s platform (Ghost(Pro) Pricing – Hosting from the creators of Ghost – Ghost.org) as they have the necessary skills to ensure that it runs correctly. I’d be skeptical that it would run correction or efficiently on another hosting platform.

Custom domains are also supported, which is great.

PROS

• Simple to setup with a managed host
• A growing plugin ecosystem
• Good Editor

CONS

• You have to pay $$ for managed hosting
• Customization options are limited

Gatsby/Jekyll/Hugo/Etc

This section is meant to cover all static sites. Static sites don’t have a database and render pure HTML to the browser. This typically results in a site that is very fast with minimal configuration and can scale very well due to demand.

While these benefits sounds great there are a lot of downfalls.

Unfortunately you need to learn a templating language (such as markdown or something else). You’ll often need to work with HTML/CSS and perhaps some JavaScript. If you’re a coder, then this might be something that is interesting to you. Otherwise, this is something you’ll ant to avoid.

However, it is important to remember that the point of the blog is so that you can start writing, not create software to render the blog. If you find yourself writing HTML/CSS/JavasScript to render you’re writing … well … what are you really doing then?

Static sites do offer a lot of flexibility though. You can code them to do whatever you want.

Want a payment form?

Code it.

Want a email opt-inform?

Code it.

Want an Image Gallery?

Code it.

Sure, there are other tools that you could use to provide this functionality, and you should evaluate those … but you get the point… a static site through one of the many static site generators.

The real rub here is that your blog is going to be written in a text editor. You typically do not get a great editor to write your blog in. Furthermore, very often you’ll need to “compile” your pages so that they’re read to go on the web. Once again, you’ll need some technical prowess to handle this.

Hosting a Static Site

Hosting a static site requires that you have a place to put the files. Typically this can be done on a web server, Amazon S3, GitHub pages, or through other services like Nelify and Zeit. You will need some technical know how in order to set these up (which is beyond the scope of this article).

As you can imagine, since Gatsby is very customizable and can be hosted anywhere (it’s just HTML) you will be able to use a custom domain.

PROS

• Very customizable
• Very fast (response times)
• Can Scale to many viewers due to it being raw html

CONS

• Hosting is not simple
• Most likely need to know how to code
• Spend more time configuring the site and writing (most likely, yes I’m pointing at you engineers).
• Technical Prowess is needed to fully use the platform

So, Which One Should I Use?

WordPress.

WordPress is the market leader for these types of sites (blogs). It has a rich plugin ecosystem that will be ready for you to grow when you need it and hosting with companies like WpEngine ensure your website is fast and secure.

You’ll find that as you need more from WordPress, it can offer almost anything you need.

Last piece of advice – try to build everything without code first.

WordPress allowed me to do that. It forced me to focus on my content and not on some cool engineering that ultimately would have acted as a distraction.

But … Can I go from X to WordPress if I like X better initially?

Sure, you can, but here again, if you decide to go to WordPress later you’re going to have to spend time migrating from one platform to another. If your goal is to write, why would you want to create more work for yourself?

Just go with WordPress now and save yourself the trouble.

📸Andrew Neel