How to Ship Side Projects
blog.andyjiang.com
blog.andyjiang.com
Especially as a solo founder (shameless plug: I run 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.
Message: TypeError: e.srcElement is undefined URL: https://resend.io/ Line: 75 Column: 28317 Stack: R</<.value@https://resend.io/:75:28317
it's not just lay a brick and you're done. my experience has been that you either solve a problem that is very single minded (bonus if it's in the consumer space) and tries to solve for one or two problems, or be prepared to face reality in hiring and scaling.
you might be able to compete on some level with the well funded companies, but you aren't going head to head with intercom or hubspot without more resources. not to mention that businesses don't want to deal with companies that don't seem like they have the capacity to support them.
And the beauty of being a solo founder (even more so a digital nomad living sparingly) is that you don't have to go head to head with the giants, even if you were to just tickle them with a stick and steal 0.1% of their customers, you'd be doing very well for yourself.
And since you cannot match their wallet, try to beat them in efficiency. With smart technology decisions, you can maintain incredibly low operational costs, while ensuring massive scalability (shout out to Elixir).
Just be careful with this line of thinking. This is the fallacy of "it's a $2 trillion market, so if we get .001% of .001%...!"
Founder: "We should enter X market! It has $1 Trillion worth of annual business." VC: "It must be heavily saturated, with mature, efficient companies. Why should we fund you?"
And now is the fallacy - instead of replying with something like "we have better A, we do B differently and we're priced at C," they say "well we don't have to take over the entire market, we ONLY need .001% and we'll be billionaires!"
And the fallacy, more specifically, is similar to an appeal to probability, because using such broad metrics aim to give the VC a false sense of confidence - that even if the founders aren't 100% successful, they only need to be .00001% successful for them to make a killing.
But it still doesn't answer the original question: How does a founder go from 0% to .000001%.
But when you're evaluating the marketplace, it's perfectly reasonable to say "I need x% of the market to break even, y% to earn a profit" and extrapolate from there. The idea itself isn't bad, it's when it's used improperly.
I set out to test this as quickly as I could and just kept going at it when I verified they were willing to backup their frustrations with their creditcard.
for example my friends brother created http://www.mailaletter.com/ and its always great to talk to him about it. (it was not making him much for the first year or so, but then it kind of exploded when people started using it in a way that he has not predicted. I forgot what it was exactly but something to do with companies needing to mail letters internationally and it being cheaper for them via his site)
Somehow I still managed to convince a few people to use it though
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".
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.
My hobbies so far haven't translated neatly into side projects, but I guess I just need to get more creative.
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 :).
Tangentially related to the article, did BetterExplained itself start out as a side project, or did you double-down from the start?
Sadly after a decade the CS department shut down my alumni account :(. But I have a cached backup here:
https://web.archive.org/web/20150708043012/http://www.cs.pri...
https://betterexplained.com/~kazad/
I started BetterExplained about 10 years ago exactly (wow), just taking some of the notes online. Thankfully they were on evergreen math topics (divergence, flux, gradients... stuff I desperately wanted intuitions for) and it grew from there.
I had been thinking of doing a decade year retrospective on what's worked/not worked in terms of keeping motivation and momentum for the projects (so far, so good). Thanks for the reminder!
Ways to 1Million in Yearly Recurring Revenue: https://instacalc.com/50021
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.
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.
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.
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) 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.
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.
J1: https://www.youtube.com/channel/UCdDhYMT2USoLdh4SZIsu_1g
JVMLS https://www.youtube.com/playlist?list=PLX8CzqL3ArzUY6rQAQTwI...
I'm sorry I have nothing more constructive than that to contribute.
But I know what you are saying, I have struggles with that inner engineer daily and he just won't shut up. :)
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.
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.
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.
If nobody would pay for it, why would you invest precious time building it? You have better things to do. :)
I can't really think of anything I've paid for where at least a solid prototype didn't already exist.
One such product I bought was https://mastermindjam.com
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.
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 [2] http://www.mos6581.org/rinohtype/
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!
Carmack said it as well: Michael Abrash and I once had a discussion kind of justifying ourselves. We said, "Well, if we shipped on time, we probably weren't ambitious enough."
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.
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.
"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.
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 :-)
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.)
[1] https://chrome.google.com/webstore/detail/fck-overlays/ppedo...