
How to Ship Side Projects - nickfrost
http://blog.andyjiang.com/how-to-ship-side-projects/
======
Tarlen
I will agree with the strategy of separating your product into sub-products,
and working on and releasing them one at a time. A single, well-executed
feature is often better than many mediocre ones.

Especially as a solo founder (shameless plug: I run
[https://resend.io](https://resend.io)), I think this is the best way to both
test your assumptions early, and to consistently ship improvements without
spreading yourself too thin.

I've taken this approach as I set out to compete with companies with 100s of
millions in funding and 100s of employees who had built out very feature rich
and elaborate product platforms.

In my specific case, it went something like

1\. build a shitty live chat plugin

2\. make said shitty live chat plugin good

3\. extend previously shitty live chat plugin with shitty automated messaging
capabilities

4\. make those shitty automated messaging capabilities good

5\. and so on..

In between each step you should try and get people to use it, be shameless.
You'll often be surprised that you can find users already at step 1, despite
competitors already rocking well-established and mature solutions.

Doing this long enough (I have been going hard for 9 months), all of a sudden
you'll find yourself with your own platform, built slowly by stacking one
brick on top of another, and sticking to it.

~~~
glennbot
Or just shamelessly ripping off intercom's product is another quick way to
iterate and test your assumptions.

~~~
Tarlen
If you can execute well and if the demand is there, that's definitely a viable
strategy to get you off the ground - Ride the wave

~~~
pc86
The product looks really good. Is the design yours as well?

~~~
Tarlen
I wish, more like some weird amalgamation of other websites blended together
with my caffeine trips and sleep deprivation. I once heard good artists
borrow, great artists steal

------
codingdave
My trick has always been to solve one of my own problems, and be my own first
customer. Then I know it works, and meets the goals of the audience. I figure
that if I need the problem solved, so do other people, but even if nobody else
ever shows up, I got my own value from it.

~~~
leeoniya
The problem is polish, documentation, marketing, promotion.

There's plenty of stuff that i've made that's useful in the form of an
inelegant API that i don't mind using. But to build a polished product with
documentation, a marketable presentation, analyze what you offer that the
competition does not, getting people interested, blogging about it, is quite a
lot more perspiration.

Writing a useful MVP is necessary, but often the easiest part. Most ideas dont
fall under "if you build it and they will come".

~~~
Clubber
Totally agree. Building a usable, shippable, commercial grade product and
actually getting people to pay you money for it is quite an ordeal. An
enormous amount of attention needs to be paid to get a product nobody cares
about installed, even for free. Even after the sale, you have to provide
support which will run at a loss until you reach a customer threshold.

The SaaS and subscription model evens out the revenue spikes, but you still
have to make the sales.

A salesman, I am not. I suppose I should learn how to do it, but I don't have
much passion for the sales side of business.

~~~
leeoniya
This is usually why you need 2 people. Someone to build the product and
someone to sell the product. There'd be no Jobs without Woz and vice versa.
Exceptions to this are unicorns. It's not surprising that the presence or
absence of co-founders is a strong signal to investors.

~~~
ezequiel-garzon
I thought the only down-to-earth meaning of unicorn was a startup with a $1B+
valuation, regardless of the number of co-founders, no? [1] Your statement
"There'd be no Jobs without Woz and vice versa. Exceptions to this are
unicorns." seems to indicate a restriction to one founder for unicorns.

[1]
[https://en.wikipedia.org/wiki/Unicorn_(finance)](https://en.wikipedia.org/wiki/Unicorn_\(finance\))

~~~
jcoffland
There can be multiple species of unicorn.

------
kalid
Shameless plug, I just launched an overhaul to a side project today
([https://instacalc.com](https://instacalc.com)).

The biggest impetus was having a friend using the old version who pinged me
with some feature requests. It reminded me that the service can help people I
know directly and gave me a huge boost of motivation. If friends and family
are using it, you'll want to help them out :).

~~~
brechtm
Doesn't seem to work on Safari (9.1.3 on macOS).

~~~
kalid
Found and fixed the bug, should be working now. (For what it's worth, I was
using fat arrow functions in javascript, which aren't supported in all
browsers yet. Forgot to compile it down to ES2015.)

------
arthurjj
Limiting the scope can't be emphasized enough if you're married with kids.

I've failed to ship 6-7 side projects because of limits to my free time. The
best side project I've successfully shipped, besides blogging, was limited to
2 "features" one of which I already had from a failed project.

~~~
TeMPOraL
So basically, try to group anything into smallest possible self-contained
utilities, until you grow a pile of them big enough that your next project can
be basically assembled from them...

~~~
majewsky
Ironically, my current side project evolved exactly the opposite way: I tacked
on more and more features, and later broke everything apart into plugins once
the correct abstraction had emerged.

------
swalsh
I used to be the kind of guy who started a lot of things, but never finished
them. I got angry at myself, and built a project with the sole goal of
finishing it. The challenge of “just get it done” really put me in the right
mindset. Since then I’ve started finishing what I started. Here’s some tips.

If you’re going to try a new to you tech, only use 1 new to you thing at a
time. There is nothing wrong with using a technology that’s old. In fact,
that’s the best way to finish something. Old technology is googleable, stable,
and usually has libraries for everything you want to do. New tech might let
you do in 3 lines what old tech will do in 20… but getting those 3 lines of
code to work might take more time than just writing the extra code. The next
point, elegance does not matter. NO ONE cares about your project. They aren’t
going to review the code, so why spend time doing something elegantly? Just
get it done.

As mentioned in the article, you really have to realize your limits. At work,
when you have a large team, the definition of MVP can expand. When it’s just
you, you REALLY need to think about what value you’re building. I’m constantly
asking myself “is this thing I’m going to spend today on actually going to be
the difference between my product being useful and not working at all”. “Is
there a way I can get away with faking, or doing this thing manually”. If you
only have a few users, you might not need to automate right away.

One more personal preference, I don’t talk about what I’m working on with
friends and family until I’m near done or done. For a few reasons, first if
you talk to other engineers, they’ll discourage you. When you propose an idea
to another engineer, they’re shoot it down pointing out minor flaws. I used to
think, oh that’s useful… they’re preventing me from going in the wrong
direction. Upon reflection though, I’m not sure the advice I’ve gotten has
always been “useful”, it has made me give up on ideas. Maybe I’m weak willed,
but this is what I need to see my ideas get done. If you really believe what
you’re building will work, the only person worth talking to are your future
customers, if your future customer isn’t interested… that’s actually worth
something.

------
shortoncash
This was a good blog post. I have shipped side projects before. What helps me
the most is to always have some really, really tiny incremental goal every
week that's achievable. This way, there's always some momentum of sorts, even
if some weeks are far less productive than others. It's when momentum dies
completely that projects don't come out of the abyss.

~~~
ehnto
I have found the same. Stressing to make massive progress or sneak in a 6 hour
session makes me burn out super quickly, and the inertia of starting a bigger
feature makes it less likely that it will happen.

I have shipped a few web projects this way and found it's been just as useful
for game development. In the rush to see progress I burnt out learning last
time, but this time I am making serious progress with just a small task each
day or every couple of days.

Also adding minor bugs that are turning into rabbit holes to a backlog for
later helps keep me motivated.

------
midhir
I find aggressive scope-cutting to be one of the most compelling things about
building side projects.

I'm shopping for computer parts at the minute so built a quick app to scan UK
shop deals, threw it up at a subdomain of my personal site (plug:
[http://slackfriday.jhope.ie](http://slackfriday.jhope.ie)) and let it go.
Over cyber monday and later it got loads of traffic and watching a stupidly
simple app do it's job was thrilling and liberating.

Even doing agile and lean MVPs every day at work nothing quite matches the
level of focus you can reach when you know your own capacity and have a time-
limit. I kind of disagree with the OP in that even if you use tech that you're
familiar with and have a fleeting idea it's still worth doing every once in a
while to remind yourself why and how people use things.

~~~
rogerdpack
how did it get loads of traffic, from where?

------
garysieling
To add another shameless plug, I built a search engine for lectures
([https://www.findlectures.com](https://www.findlectures.com)).

A great thing about this is that there is no point where it's "done", as long
as it has enough content to be useful. As I get more data, it unlocks tons of
opportunities for mini-projects. Writing a blog has been a good side-project
for the same reason.

~~~
monksy
That's pretty cool. I would love to see the JVMLS or JavaOne videos to be
listed there.

J1:
[https://www.youtube.com/channel/UCdDhYMT2USoLdh4SZIsu_1g](https://www.youtube.com/channel/UCdDhYMT2USoLdh4SZIsu_1g)

JVMLS
[https://www.youtube.com/playlist?list=PLX8CzqL3ArzUY6rQAQTwI...](https://www.youtube.com/playlist?list=PLX8CzqL3ArzUY6rQAQTwI_jKvqJxrRrP_)

~~~
garysieling
Thanks! I'll add these to the list.

------
Pyxl101
I wanted to read this post but I couldn't get past the light grey font which
was very hard to read. Illegibly thin and light fonts like this are borderline
hostile to users, and frustrate me every time I encounter them.

I'm sorry I have nothing more constructive than that to contribute.

------
urs2102
I really like the idea of approaching rapid development like writing an essay
or a blog the first time. Just getting all the words out on the paper goes a
long way; same thing goes for programming.

~~~
blackflame7000
I understand your mindset, but sometimes a little bit of planning upfront can
save so much time in refactoring. I'm not sure code is analogous to writing
save for maybe a choose your own ending type novel. An Essay is essentially a
sequential flow of ideas where as a program is more like a tree. Perhaps what
you are referring to is rapidly developing the nodes(classes) of that tree
without concerning yourself to much with the connective branches between
classes. If that's the case then I can see the benefit.

~~~
Drdrdrq
From purely technical viewpoint that is correct and engineer in me agrees with
you 100%. However: if you look at the bigger picture you will notice that the
feature list is not known in advance. Which means the nice abstraction you
made are probably unsuitable and will make repurposing software _more_
difficult, not less. Because nobody knows what the end product will look like,
so it pays to ship fast, iterate on product design and refactor / rewrite
later.

But I know what you are saying, I have struggles with that inner engineer
daily and he just won't shut up. :)

------
bharani_m
I am working on a side project called Metriculator
([https://www.metriculator.com](https://www.metriculator.com)).

This is my personal experiment to see if I can build and market a full-fledged
SaaS tool. It has also been a nice way to pick up a new programming language
(Elixir).

I have a lot of unfinished projects. I start working on a new idea, build out
some functionality and then the interest fizzles outs and the project is left
unfinished.

This time, I decided to take a different approach - I decided to keep
publishing the app incrementally. I started off with just a landing page
first, last week I added the demo survey. There are a LOT of things left to be
done before I can roll out public access to this project, but getting a few
beta users has been a nice inspiration to keep me going.

------
adamgamble
I've really enjoyed this comment thread because I started feeling like
everyone was shipping their side projects but me. Turns out I was only seeing
the highlight reel. Weirdly, the fact that everyone seems to have problems
with this, encourages me to keep trying to work on it.

------
huan9huan
I agree "Ship it" part. My previous side projects is always by this styles:
"good idea" (1 week) => develop it (2 week) => "not satisfaction" （several
days） => abandon => next idea .... The passion always dispears after one
month, so in one month, need ship it. BTW, the Show HN is really really good
channel for every early shipping.

------
ticktockclock
Scope creep is the enemy. I'm a big fan of the minimum viable product idea.
What is the smallest thing you can build that lets you quickly make it around
the build/measure/learn loop.

------
skbohra123
One big issue with working on side projects is that you get emotionally
attached to it and sometimes it takes over your mind, more than it should.
Learning to balance that would help you be at peace at slow speed of the side
project, after all it's called side project for a reason.

~~~
kchauhan
How you manage in that case?

------
ThomPete
As a designer this become even more problematic.

I have been depending on developers to do the hardcore development (I can do
web-coding myself well enough) and are therefore depending on convincing
developers to help me.

After a number of attempts at starting various products/services with various
levels of success but ultimately fizzling out.

Ex. Weekendhacker have around 8K designers and developers subscribed but it
kind of died out, because the time i spent vs. any income I made was not
making sense. I haven't killed it but it's basically in hibernation until I
figure out what to do with it. It was a really frustrating to see something
like that die out with such high hopes of starting an actually community.

However I finally managed to launch something that is generating growing side
income for me year over year, which I can control the progress of and which
allow me to expand slowly but surely.

[https://www.ghostnoteapp.com](https://www.ghostnoteapp.com)

Now GhostNote is only the start of something much bigger I am building but it
allow me to control the scope and slowly expand what I am doing while still
enjoying it as an added bonus I am making good money.

You should ask yourself the questions like.

Why am I building what I am building?

Is there a simpler way to do what I want to do. (Ex. could it just be email to
start with? Weekendhacker was.)

Is this really what I want to spend my time on?

Does the world really need this?

But most importantly you should never give up, sooner or later you you wil
find something as long as you make sure you don't spend too much time on each.

I have literally hundreds of ideas, a whole graveyard of almost implemented
projects

Just keep trying new stuff, make new alliances with developers. Do several
things at once if you have to. But if you want to make money with your side
project don't be too attached.

------
Swizec
Start with a credit card form.

If nobody would pay for it, why would you invest precious time building it?
You have better things to do. :)

~~~
xiaoma
And if everyone followed this advice, we'd have no Kahn Academy, no Wikipedia,
no Linux and a much poorer world.

~~~
Swizec
None of those are side projects. There's a time and place for change the world
free stuff and a busy person's free time is rarely it.

~~~
jacalata
Khan Academy history
([https://en.wikipedia.org/wiki/Khan_Academy](https://en.wikipedia.org/wiki/Khan_Academy)):
The organization started in 2004 when Sal Khan tutored one of his cousins on
the Internet using a service called Yahoo Doodle Images. After a while, Khan's
other cousins began to use his tutoring service. Because of the demand, Khan
decided to make his videos watchable on the Internet, so he published his
content on YouTube.[9] ...The critical acclaim and the positive responses of
students prompted Khan to quit his job... and focus on the tutorials

------
p0larboy
Aggresive scope cutting while maintaining the usefulness of the app is tricky
but will payoff for that elusive launch day

------
sumanthvepa
The biggest problem I've had with side projects in my past jobs was that my
employment agreement was all encompassing and I would require my employer's
explicit permission to release the project. So I pretty much stayed away from
them except as purely throwaway learning exercises.

------
epynonymous
i think reid hoffman's quote (linkedin founder) sums it up best, "if you're
not embarrassed with the first version of your product then you've launched
too late."

i have seen many posts about mvp and narrowing scope here--all right on the
money.

some other things that have worked for me, i'm the world's biggest
procrastinator and i have literally 20-30 side projects that i've started for
some time, was extremely passionate about, and then moved onto the next big
thing, but i've recently had a few projects that i went deep on and actually
got out, even hoping to build a business out of.

i've also found that the technology stack is not that critical, as a
perfectionist i want to create a kickass platform that's easily maintainable,
beautifully coded, using all the right tools that can meet billions of
requests per day from the start, easy to deploy, automated, etc, but that
typically just leads me down a huge rat hole. if your energy is finite (for me
it is), you should focus all of it on getting your stuff out the door as
quickly as possible, getting it in front of potential users because often
times what you think is a great idea is raw and will need tuning. make things
functional, able to showcase your main idea (or a particular use case), don't
have to have all use cases fully done. get it out there and iterate. i'm
certain that there are people that can make all the right technology decisions
from the get go to support billions of requests per day, fully automated (if
you are one of these, please email me right away!) but you're solving the
wrong problems, if you want to get a side project or business out there, go
build it, get it out there and then iterate, and iterate fast.

for the sake of argument, probably side projects like tools or libraries,
these are a bit different in nature, you probably want to choose the right
technology stack, etc. but if you want to build a business out of your side
project, then don't dwell on this too much, use what you're familiar with that
can give you the quickest turnaround, there will be pains with whichever tech
stack you choose, some more than others, but it will pale in comparison to the
roadblocks in front of you to build something into a business.

for one of my recent projects, i use sqlite3 for my relational database, i
don't even want to spend all the 30 minutes or whatever to set up postgresql,
it's to that level of scope reduction. when users grow, then i'll spend the
time to upgrade and add backups, etc.

~~~
brechtm
But what's an MVP? That's very subjective.

I'm working on a DITA (to PDF) renderer [1] based on rinohtype [2]. About a
year ago I was in a startup coaching project. I was advised to put out an MVP
ASAP. Since then, I've worked full-time on the project and only now I'm
releasing what I believe is an MVP. One year ago, my product was functional,
but it didn't allow easily styling the output PDF. I believe this is the
feature that differentiates it with the competition. I feel that, without this
feature in place, my product wouldn't offer anything interesing.

I could have also released an "MVP" much earlier, but say it couldn't render
tables. Who would've taken it seriously then? Even if I added this feature at
a later point, how many of the people that tried the first version would
bother checking it out again?

For some (new) markets, I'm sure you could crank out an MVP in a month. But
for existing markets, there's the established competition that sets the bar,
no?

[1] [http://www.opqode.com/rinoh](http://www.opqode.com/rinoh) [2]
[http://www.mos6581.org/rinohtype/](http://www.mos6581.org/rinohtype/)

~~~
epynonymous
no doubt, you raise an excellent point--mvp is somewhat vague, hard to
quantify, and there's no universal answer so unfortunately the answer is it
depends on the idea/product/lifecycle. chances are if you're still trying to
get a feel for a market, this could be an entirely new market, one that
doesn't quite exist, or an existing one with incumbents, like airbnb as an
example, an mvp could be like a simple mobile app with login (not even oauth
based for facebook/twitter/google), listings, a way to book, and bill. don't
implement user feedback on listings where they've stayed, don't implement
icons for users, forgotten password is an email to support, etc, i'm sure you
could find a million things that are needed, but what are the essentials for
getting people to use your app satisfying some specific needs (crashing at a
complete stranger's place). each feature doesn't really need all the bells and
whistles, enough to get people to start using the basics. your assumptions and
hypotheses about how the market would leverage this tool could be entirely
off, so you might need to change direction (pivot more or less) and you'd need
to get to this conclusion asap, sooner rather than later, etc. if you spent a
year coding something you think would be perfect for a market you are defining
or discovering, this could be a large waste of time, so fail fast as they say.

in your case, you seem to be quite clear about what you need, what the
competitors have and don't have. but let me play devil's advocate because i
don't know how much effort "[rendering] tables" would take or how much you've
put in the past year, but let's just say you could put something out there in
6 months time as opposed to 12 months time, it probably will have some table
rendering, not 100%, but do you think that would be advantageous or not?

thanks for the footnotes, much appreciated and good luck with your app!

------
amorphic
I wrote this a while back which touches on some similar points:
[https://jimter.net/open-source-the-journey-from-project-
to-p...](https://jimter.net/open-source-the-journey-from-project-to-product/)

------
kaa2102
This is smart. Start by developing the smallest and most essential solution to
a problem, get feedback, and incrementally improve the solution.

------
rogerdpack
I like it, except for the part about "refactor later" in my mind the best way
is refactor "first" so that adding your feature is "easy"...though I don't
always follow my own advice with hobby projects LOL. Don't let technical debt
subsume you, though, fight back eventually.

~~~
rogerdpack
I do like the part about focusing on "the next feature for your customer"
though, customer centric can take you far, that's good...most/many hobby
projects focus on only the next "feature for me" and never get around the
marketing/polishing side of things, whereas focusing on customer-ish stuff
encourages the latter, the latter being 80% of success typically overall (or
get a partner to do that part, the common successful way there...)

------
netrap
I just want to say it is OK to give up from time to time. I had a serious side
project I worked on for 2 years. Sometimes you need to cut your losses. I was
able to use a product that cost me $100, though it doesn't work exactly as I
want, it does the job. So just ask yourself, is this worth it?

------
repeek
If you need some additional motivation, I recommend Just F*cking Ship
([https://unicornfree.com/just-fucking-ship/](https://unicornfree.com/just-
fucking-ship/)). It helped me get out of a rut and focus on what's most
important.

------
logicallee
I'm going to go ahead and disagree.

I suggest that instead of this approach, you take an _approach_ of starting by
overengineering it and making it absolutely perfect in every way - then just
ship the part of that you manage to actually do.

Sometimes the best way to write a short story is to write a three-volume epic.

~~~
SwellJoe
I think I'd need to see some evidence that that is a more effective strategy
than starting small.

My biggest enemy is always analysis paralysis. The bigger the project, the
less likely I am to ever even start, much less finish anything. Likewise, when
I do start, if the scope is too big, I'll flit from concept to concept never
really finishing any of them. But, when I have a very small, concrete, and
actionable item, I can knock it out in no time...it almost doesn't even feel
like work sometimes.

I don't think the "overengineer it" approach could ever work for me.

~~~
logicallee
>I think I'd need to see some evidence that that is a more effective strategy
than starting small.

"To begin with, GNU will be a kernel plus all the utilities needed to write
and run C programs: editor, shell, C compiler, linker, assembler, and a few
other things. After this we will add a text formatter, a YACC, an Empire game,
a spreadsheet, and hundreds of other things. We hope to supply, eventually,
everything useful that normally comes with a Unix system, and anything else
useful, including on-line and hardcopy documentation."

Looks like he did all that. (Mostly in the form of Emacs). Anyway it's hard to
get more ambitious than a list like that. Other early announcements of
effective projects were the same - very large vision.

~~~
SwellJoe
Counter-argument: GNU was a copy of an existing reasonably well-engineered and
well-documented solution, in almost every piece. Sure, GNU utilities often
improved or extended the standard, but the design already existed. Further,
GNU is a system of many discrete parts. Each piece could be built by an
individual without tight interdependence on other pieces. That's an MVP.
Small, useful, pieces, that add up to something bigger.

I believe GNU is evidence of the opposite point you're trying to make. Unless
your point is actually "think big, but build in small, manageable pieces", but
if that's your argument, that wasn't how I understood it.

Ambition is not antithetical to building in small pieces. In fact, I think
most people have to start small.

While we're on the subject, I'll quote another kinda famous first
announcement:

 _Hello everybody out there using minix –

I’m doing a (free) operating system (just a hobby, won’t be big and
professional like gnu) for 386(486) AT clones. This has been brewing since
april, and is starting to get ready. I’d like any feedback on things people
like/dislike in minix, as my OS resembles it somewhat (same physical layout of
the file-system (due to practical reasons) among other things).

I’ve currently ported bash(1.08) and gcc(1.40), and things seem to work. This
implies that I’ll get something practical within a few months, and I’d like to
know what features most people would want. Any suggestions are welcome, but I
won’t promise I’ll implement them :-)_

~~~
logicallee
>Unless your point is actually "think big, but build in small, manageable
pieces", but if that's your argument, that wasn't how I understood it.

Unfortunately, that was exactly my point!

I've made a modification to my original comment: I've italicized the word
"approach" now, to emphasize that this is just the kind of _attitude_ you
should have.

Basically, my main point is that if you don't overengineer a perfect and very
ambitious solution, you're unlikely to ship anything - but if you do, then you
are more likely to ship it, even though obviously you will start shipping some
small part only.

It would be interesting if there were some way to do a double-blind
experiment, giving a thousand people a couple of different approaches and to
see who ends up shipping :).

in short, I'm saying, by targeting something _huge_ and overengineered, you
are more likely to ship _something_ (anything at all) - versus targeting a
minimum; which leaves you less likely to ship anything worthwhile. I am not
saying by targeting something huge and overengineered, you are going to ship
something huge and overengineered. Rather, that you will end up shipping a
small part of it. (And that this approach is better than the alternative.)

------
flippant
Maybe the "tenth callback" is just a bad example, but I would emphasize not
doing anything that will sap your motivation on the path to shipping. For me,
that's having to deal with brittle code when I'm constantly reevaluating the
requirements.

------
gejjaxxita
I really enjoyed reading this. I have been stalling on a side project for some
time and this article has given me some ideas with how to proceed.
Specifically narrowing down the requirements.

------
reedlaw
Sorry but those animated gifs distracted me from reading. Normally I will
scroll things like that off the page but when they come so close to each other
all I see is the movement.

~~~
rcdmd
We're now coming full circle [1]... Chrome's inspect element followed by the
Delete key works wonders though.

[1] [http://www.wonder-tonic.com/geocitiesizer/](http://www.wonder-
tonic.com/geocitiesizer/)

~~~
anchpop
There's a chrome extension I find very useful that adds this to the right
click menu called "f*ck overlays" [1]

[1] [https://chrome.google.com/webstore/detail/fck-
overlays/ppedo...](https://chrome.google.com/webstore/detail/fck-
overlays/ppedokobpbdajgiejhnjfbdjlgobcpkp)

