
Side Project Launch Checklist - userium
http://keepwomen.com/static_pages/checklist_tool
======
shocks
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.

~~~
whistlerbrk
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'.

~~~
userium
"..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.

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

~~~
thoman23
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.

------
onion2k
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.

~~~
userium
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.

~~~
onion2k
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.

------
jkaptur
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.

~~~
cableshaft
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.

~~~
jkaptur
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).

------
ser_tyrion
"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.

~~~
jon-wood
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.

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

~~~
k__
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?

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

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

------
dsugarman
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.

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

------
vdnkh
>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?

~~~
thoman23
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.

~~~
vdnkh
>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.

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

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

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

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

~~~
siavosh
This is one good resource:
[https://www.owasp.org/index.php/Web_Application_Security_Tes...](https://www.owasp.org/index.php/Web_Application_Security_Testing_Cheat_Sheet)

------
netman21
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.

------
briholt
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.

------
kylehotchkiss
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.

------
agentgt
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.

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

~~~
agentgt
Oh I completely missed that Bibliography link.

