Part 1
Let me tell you a story. A few months ago, May 5, to be exact, I went to the Gatsby Days conference in New York City. A week before that, I set a goal for myself to launch a new personal website prior to the event.
I'll write I separate BTS post because Gatsby is cool, and I learned a lot along the way. This article is not about that.
A week before the conference, I had the design, page structure, and a bit of experience building websites with and without Gatsby. I was going to go with a super minimal layout, a few pages, and contact info. Sweet and simple.
Fast-forward to the day before the event. I'm sitting in a lobby of the Ace Hotel in NYC (It's a cool place to work from) coding what I then thought were last pieces of the site when the devil's voice appears in my head.
— Dude, you haven't built the blog at all! That's not cool.
— Yeah, I know, I don't want to add it. I wrote my last post in December 2016.
— But you need a blog. You have to blog.
At this point, I should have shut that voice down, finish what I was coding and launch. But I didn't, and the voice kept going.
— Look, I know it's been awhile, but you'll pick it up and start writing again. You loved it, remember?
— Yeah, you are right...
— On top of that, what happens with all those articles on your old website? Are you just going to abandon them?
— I mean... There are not too many articles, and, honestly, no one really reads them. I was young and inexperienced when I wrote those.
— But that's history. You don't want to erase your history. Do you?
— I don't, you are right.
See where it's going? The voice went on.
— Look, why don't you quickly lookup how to move your posts from WordPress to Gatsby? You still have a few hours.
— Yeah, that's right, I can do that, let me figure this out.
— That's my man!
Those were his last words that day.
I looked up what I can do to add a blog to my Gatsby site, and realized that It's a bit more complicated than I initially thought. I didn't have the design for posts. I had to style the content, add taxonomy pages, figure out how to turn regular images to use the Gatsby Image component, and code a bunch of other things.
Long story short... I decided to launch the website a few weeks after the conference with a blog.
Part 2
Fast-forward to the present day. It is October 31, and as I type this sentence, the website is still not launched.
Let me tell you what happened. I started working on adding the blog. Then I decided to add case studies. Then I thought that I could have a different color scheme on the about page, then I added animations. The list goes on.
I did work consistently on this project for at least a few hours a week in my free time. And it was very rewarding because I learned a lot about React, Gatsby, GraphQL, Intersection Observer API, GSAP, and many other cool things.
But looking back at these few months, I see one big mistake. I kept working locally and never pushed the site live. I also didn't share anything I've learned along the way.
So why am I telling you all this? Because it is a very easy trap to get into. And because I found myself in the same situation that happened in May. I'm sitting on a plane to St.Louis, where WordCamp US 2019 is taking place. And again, it makes sense to launch the website before the conference. And again, I have many things to work on, and there is only one day left. And again, while I was boarding the plane, I heard a familiar devils' voice. Only this time, our conversation was much shorter:
— You still haven't migrated all the posts from your old website. And not all animations are smooth. That's not cool.
— F$ck off, I'm launching it today.
How To Launch On Time
So what is the lesson here? How do you launch projects on time (especially your personal projects where you are the client)? I'm sure I'm not the first person to tell you this, but here's the approach that works:
Step 1. Define the MVP version of the project. The bare minimum amount of features you can build in a very short time that are enough to make the project work.
Step 2. Get to work, focus on those features, and build them.
Step 3. Launch. Get yourself in a champion state of mind and ship it.
Step 4. This is where you catch momentum. Now you need to repeat the steps. But the magic of this step is that now you can collect real feedback and use it to define the next set of features.
Dangerous Trap
During Step 2, you will discover that some of your initial ideas don't work. Or you will come up with better ones. You will be tempted to rewrite parts of your project, redesign screens, refactor the code; in other words, make the project better.
When this happens, ask yourself: "Can this be done after the launch?" Most of the time, the answer is Yes. Don't rewrite, fix, or redesign now. Ship it, and update later. (but not too late, keep the momentum). If the answer is No, ask another question, "What can I do to launch it on time?" Find a workaround, change the scope, be creative, and get it out there.
Wrap Up
I wrote this post mostly to remind myself that shipping things consistently is one of the essential skills a developer can master. And I have to work hard on that myself.
Don't delay the launch of a project because something isn't 100% ready yet. It never is. There is always room for improvement, but this not a valid reason not to ship it.
So If you have something you are working on for a while, don't wait to get it out there. Do it as soon as you can. Don't listen to the devil, tell him to piss off and launch!