Side Project Launch Checklist | Hacker News Reader

Side Project Launch Checklist

keepwomen.com

120 pointsuserium48 comments

I don't think this is a good list for a side project.

Every side project I have ever attempted has taken me ages and never got anywhere. Saying things like localisation need to be done before your MVP ready is nuts.

I'm working on a side project right now. I've tried to learn all my lessons from other attempts. It's just a basic website (landing page). Between building that, trying to sort out product, make a plan, etc - there is barely any time left... I have a full time 9-6 job, and a two hour (total) commute. There's hardly any time left at the end of the day, squeezing out an hours work each day is hard enough. Localisation would never be on my list.

Having the time to check each one of these points is a luxury most side projects can't afford.

I agree I would never launch anything if this was the standard, however, this is a good check list if it's a 'side company'.

Not really, I know a bunch of companies that would fail lots on this list but are making millions.

For a side project you'd probably be better off putting much more basic things like 'does it work on mobile', 'do the email addresses listed actually work', 'is robots.txt still set to disallow google' and 'have you actually gone through a whole order yet' on there. Seriously.

I still don't think I agree, sorry. You might want to make something as good as possible so people are more likely to pay for it, but all the time it's not launched nobody is paying for it at all.

"..this is a good check list if it's a 'side company'"

That's actually a better term! It makes a difference whether you are building the side project as a creative hobby (to develop new skills etc.) or in the hopes of turning it into a startup.

back in the day we used to call that a "lifestyle business"

Eh, not really. A lifestyle business is your main source of income. It's not a side project. It's just not a startup because there is no massive growth expectation.

I like the list... Just think of it less in terms of "have I done this?" and more in terms of "have I thought about this and made sure it isn't important to my project?"

Ya I agree. I think there are some basic sanity checks that are easy to forget in the rush to get shit done before launching a page. My minimum viable checklist:

1) Does it work in a bunch of sizes on laptop/desktop monitor?

2) Is it readable/usable on my iPhone?

3) Does www.mysite.com and mysite.com work?

4) Do I list contact info for someone to reach out to me?

5) Do I have some way of capturing signups?

6) Do I have a google analytics snippet working?

7) Is my static content behind a CDN so I don't go down in an easily avoidable manner?

I like to leave this checklist open ended since my definition of 'working' on mobile vs. desktop depends on the project. If I'm throwing an event, it's very important that people are able to register on mobile...if I'm launching an e-commerce store, they might not need to buy but just add their email address.

What exactly is it about the things you've listed that makes them important? The majority of successful businesses that I've seen launch broke pretty much every point on that list when they deployed their first version, and most didn't fix them for months (and years) afterwards.

If I was making a similar list it'd be something like:

1. Does the product do something useful yet?

As soon as the answer is "yes" then you should launch. That's it.

I think that by fixing common problems before launching, you get more meaningful feedback later from your users. They won't concentrate on the obvious problems that could have easily been fixed.

The benefit of launching earlier far outweighs the annoyance of trivial feedback. If someone is genuinely interested in the product they'll be willing to overlook critical show-stopping bugs that destroy data in order to help you get the product to a point where they can start paying to use it. A few missing alt tags won't make the slightest bit of difference to the user, and that's the person who matters.

But failing to launch of a month while you 'polish' things will make a difference. You'll lose out on feedback, potential customers, and give more foothold to any competition. Plus it's boring and expensive to not launch.

People who'll walk away because there's a spelling mistake on the contact page would never become paying users regardless of how great your product is. Ignore those people.

I don't think I followed any of these for my side project (www.diff.so) because, well, it's a side project! It's a prototype, something I did for fun. This is a great list of things to do before I expect someone to use it seriously, not a pre-launch checklist.

To go a bit off-topic, I actually tried to follow the "don't use color alone to provide information" for the static diff on diff.so/about, but I couldn't find a way to get ChromeVox to read text on one side of the diff any differently than text on the other. I'd be really interested in any advice on that - it seems like some screenreader users could use something a little more user-friendly than emacs.

"It's a prototype, something I did for fun."

The goal of your side project makes a difference I suppose. People build side projects, either as creative hobbies, or some in the hopes of turning them into startups.

Nice site btw.! :)

Oh wow, your site is exactly what I needed. I've got diff programs, but they focus more on differences over a full line, instead of word by word. But I write stories and have a bunch of ooooold versions that I always wanted to compare on a word by word basis, and your website should save me some significant time comparing those.

Oh cool! I'm glad to hear it. Let me know if there's any way I can make it better for you (although, like I said, it's a thing on the side).

"Personalized Features: Language" sounds like a lot of work for not much payoff. Halting the launch before translations are ready will get in the way of 'just shipping'. That said, probably a good idea to dev with js i18next even if all translations aren't ready.

That's true, not all these things are equal priority. I do agree that launching quickly is important to start getting feedback from the users. But by fixing obvious issues, you get more meaningful feedback from the users.

I agree, localization is a massive investment for doubtful payoff when you don't even know yet whether anyone needs what you're building. Also, on my most recent project, as soon as I had paying customers, some of the international ones offered to help with the translation work.

Having added localisation to applications after a few years of not considering it I now try to build all but the most trivial tools with it in mind. In most cases the only locale will be en-GB, but having at least considered the possibility early on makes the process of adding that second locale infinitely less painful, and by extension the thought of expanding into other markets less scary.

The creator of keepwomen.com here, if anybody wants to discuss? I'm happy to hear about improvement ideas for the website!

I like the list, but seems to be rather much for a launch.

How about doing a poll to get the most important points and apply the Pareto principle?

Good idea, not all the things are equal priority. They do require different amounts of effort.

Ah yes, effort should be taken into account too, so you get the quick-wins at the top.

By "uppercase", did you mean "all capitals"?

Yes, capital letters.

Awesome site!

Thank you. Please let me know if you have any ideas how to make it even better! :)

The list is nice and thoughtful. Thank you.

You could add a total (15 points out 40 todos) to make it even more useful.

Personally I would just title it as "Website Launch". I do side projects which are for self-learning or help a few friends. They are useful for a few users but they are not meant to serve hundreds or millions of users.

Thank you, good ideas!

I'm a man, does this all still apply to me?

I think this is a much better checklist for people who already have a product out there and want to get it from gritty MVP for early adopters to polished product.

The fact is, your first version should be shitty and you should release while you are still embarrassed about it. There's no numbers on this because they would be impossible to get, but I would assume over 90% of projects never see the light of day because most people never get it to that perfect state that they wish to launch at. Don't be one of those people, launch and get feedback ASAP.

Much of this goes against conventional wisdom for launching an MVP.

>Links are easily recognizable. They look clickable. Items that aren't links don't look clickable, for example underlining text is avoided.

I've been struggling with making things 'look clickable' on my website (or maybe everything is fine and it's in my head). To solve this I've been trying to define what exactly makes a user want to click something. The most common methods are the blue link color, underlining, or a 'more/click me' button. I don't want to do any of those - wanting someone to click content is more desirable than telling them to.

In researching other sites and monitoring my own behavior I noticed that I always want to click images. This probably has to do with being a long time image-board browser. But the content I want to be clicked doesn't have any images associated with them. I've been trying to work in glyphicons that indicate a link, but it messes with the aesthetics of the content.

Any suggestions?

Honestly? I'd say don't reinvent the wheel. Underlined links with the changing cursor and/or clickable buttons are what the user expects, so give it to them.

>Underline links

I would, but I want an entire paragraph (title header + body) to be clickable. It looks pretty bad if the entire thing is underlined, and just underlining the header makes it look like a decoration and not a link. The cursor does change but there's no cursor on a touchscreen.

So make the entire paragraph clickable, but only underline/color the title header.

That was my conclusion too, going to try this out when I get home

"The most common methods are the blue link color, underlining, or a 'more/click me' button. I don't want to do any of those - wanting someone to click content is more desirable than telling them to."

A user isn't going to click anything unless they know they can click it. You have to tell them they can click it before they can want to click on it. And the easiest way to do that is with the blue color or the underline.

Depends on what your definition of a side project is, but I would add a security list as well.

Good idea, any suggestions on what to add on the security list? SSL, ...

This is one good resource: https://www.owasp.org/index.php/Web_Application_Security_Tes...

Of course you do not need a URL redirect to get the primary domain to go to www.domain.com That is handled in your DNS "A" records.

This is a bad list.

First, it's basically a list of minor nit-picky random things rather than a thoughtful list of essentials. How is "Pages don't refresh automatically" on the list, but, "Buy an SSL certificate" is not?

Second, many of these things would be total waste of time pre-launch. If you have zero people buying your product and you spend your time perfecting "Currency, language, country specific deals, taxes" then your perspective is way out of whack.

It feels to me like this list was put together by a committee of people who read TechCrunch everyday, but have never actually launched any side projects.

this is a good checklist for real projects too. As a developer, it's hard for me to see big-picture what matters because I have my head buried in the code.

Since the check list is mainly opinion based (I didn't see any stats or references) I would add that it in my opinion you should get an SSL certificate.

It was the first thing I noticed when I clicked on the link. Perhaps to many audiences this isn't important but I know for some it really does matter.

On the bottom of the page there is a link to a bibliography. You are right about the SSL.

Oh I completely missed that Bibliography link.

Reply on news.ycombinator.com