My playbook for shipping side projects

Here are the tips and strategies I've learned from shipping many side projects over the years, including my personal site, Security Checklist, Staff Design and Design Details:

Be interested in something for so long that you can't ignore it

You're probably going to work on a side project for a few weeks. Maybe even a few months. Or if you're an absolute mad person like me, you might work on a side project for years. Between design, development, marketing, and iterating post-launch, you will need some intrinsic motivation to push through all the boring parts.

So it feels silly to have to say this out loud, but I think it's important to pick your side projects carefully, using some threshold of "sustained interest" that determines what to build. For me, that threshold is "I haven't stopped thinking about this idea for at least two weeks."

Note: this strategy also works for prioritizing bug fixes and feature requests at my day job. Our team writes everything down, and the important stuff will keep bubbling back to the top. The one-offs and unimportant ideas will fade into the background.

Build an ongoing communication channel

Marketing is hard. I'm not good at it, yet. But this point is so fundamental that it's worth stating out loud: you must have a way to tell people about the work you are doing!

But Brian, if I build it won't they come?

Probably not. Maybe! Why take the chance?

I've found email lists to be consistently straightforward and deliver solid results for communicating with interested people. For example, Staff Design had ~2,000 emails on launch day. Design Details had around 1,500 emails at launch. The number here represents people who are more-than-superficially interested in what you have to say: they are more likely to share what you've worked on, give you candid feedback, and in general add the kind of excitement and energy to a launch that makes everything feel worth it.

Respect this communication channel! Do not abuse it. There are too many tools that exist to help people quickly unsubscribe and mute unimportant spam.

Tips and tricks for setting a ship date

A lot of people make up excuses to never ship their side projects.

It's not ready! It doesn't have all the right features! There's this one super obscure browser bug that I need to fix, the infrastructure won't scale to a billion users...

It's really easy to fall into this trap: there's always something you can do to make the design better, or improve a feature, or make the copywriting better.

Here are three tricks I've used that helped me avoid these excuses:

Determine a minimum quality bar that triggers a ship. Write out a list of all the features you need for a v1. When you've checked those boxes, ship. Avoid scope creep at all cost. There will be bugs, and you will be able to fix them later.

Determine a minimum content volume that triggers a ship. For Design Details we wanted to record 8 episodes before we launched. We ended up pre-recording 5. For Staff Design, I knew I wanted to ship with exactly 8 interviews. I recorded all 8 interviews before the first one was published. I like this trigger a lot because it forced me to front load all the actual hard work. After launch, I'd bought myself a few weeks to reflect and plan my next steps – including whether or not I want there to be any next steps!

Determine a date that triggers a ship. This is probably the least compelling trigger because it feels the most arbitrary. But if you're a deadline-driven sort of person, then just pick a day and ship on that day. Don't make excuses, just ship what you have and iterate quickly to tie up any loose ends. Having your imperfect work in front of real human beings will provide the motivation needed to crank through the last few bugs and polish nits.

I loosely followed this strategy for Staff Design: I started working on the project in December and decided that I didn't want to get to February without having shown something to the world. So I publicly announced that I would launch mid-January and ended up shipping on the 19th. I ended up clarifying a lot of the copywriting and fixing small visual bugs in the 24 hours post-launch thanks to feedback from readers.

Work with the garage door open

Some people love to build in secret and then drop the mic on launch day. I prefer the alternative: talk about what you're building, while you're building it. This is important to me for two reasons:

• It lets you work with the garage door open, which invites interest and investment from people who are likely to care about your project. It's exciting for others to see the iteration, the improvement, and have it all culminate in a launch.
• It's important to me to "bring people along for the ride." I think that working in public does much more than we realize to inspire others. Sharing more openly as you learn and iterate helps your audience to build shared understanding along the way, making the launch more meaningful and contextual.

Create multiple launch days

Launch days are exciting, but usually short-lived. You get that day-one spike of traffic and tweets and then things slump hard. That slump is demotivating. One way to avoid this is to not think of launch as a single day event. You can spread your launch over multiple days by talking about the meta of your project in subsequent emails or blog posts to create sustained interest and reach a tangentially-interested audience.

How do you talk about the meta of a project? Here are some ideas (note: this blog post is doing this exactly thing. Double meta!):

Write about the launch results themselves: traffic, revenue, or signups. People love to peek behind the curtain of a successful launch. Daniel Vassallo has become very well known for writing about the meta: he shares his revenue, expenses, ongoing experiment results, and discoveries all the time. He was even able to turn this meta context into its own revenue-generating project!

Write about what you learned from shipping: how the project evolved over time, what you wish you'd done differently, or what the most interesting challenges were. Who doesn't love a good retro?

Talk about what didn't ship: features you cut, scope creep you fought back, or even more future-looking plans on your roadmap that people can look forward to.

Anticipate the long-tail visitor

In the long run, most people who visit your project probably won't know about you, or the launch itself, or have the full context of how you arrived at the final product. It's important to keep these stragglers in mind: the copywriting and value proposition of the product should be clear for first time viewers.

I actually made this mistake on Staff Design: I designed the website under the false assumption that everyone who was reading the interviews would have some context about the project's theme. But of course this just can't be true, and so I had a lot of people clicking links directly to an interview page and being confused about what the purpose of the site was.

To fix this, I put in a banner that only appears for users who land directly on an interview page. It can be quickly dismissed and prompts people to click through to learn more about the project. This banner is set up so that people who have previously visited the Home page or About pages will not see it.

You can see this in action by opening an interview page in an incognito window.

C-c-c-combo side project launches

All of the things mentioned above compound when you put the playbook into practice a few times in a row. A growing mailing list, a body of work that sees long-tail traffic, and infrastructure for writing about your process, will all make the next project faster and easier to ship.

If you are clever and anticipate how your network of projects will evolve, you can design your email lists and marketing channels to be additive and not siloed to a single project.