One tip I've picked up from experience: avoid projects that have user accounts.
If your project has user accounts, you'll get users who you have to take responsibility for. Then it's not a side-project any more, it's a part-time job.
These days I much prefer side projects which have no user accounts at all (like https://www.niche-museums.com/) or that are open source tools where the end user installs and uses the software without me having any involvement at all (like https://github.com/simonw/shot-scraper)
I ran a blog for over a decade, with comments open. A typical post would get 10 to 30 real comments and tons of spam that got filtered out.
Why was this such a disastrous choice? I enjoyed having the site and with the exception of a couple of heated arguments in the comments, and spam, it was never a concern at all. Even the spam was very minor inconvenience since the filters caught pretty much all of it.
Many of my friends walso ran blogs in the late 2000s to early 2010s and the majority were smaller and had zero arguments in the comments and less spam as well. Just a comment or two on the occasional post.
Aren't you implicitly betting on yourself not to succeed though? There's some cutoff of eyeballs where moderation becomes painful, and it's a pretty steep pain.
My goal was never to get a Tim Ferriss-sized audience. It was primarily for personal expression at the beginning and then gradually grew over time.
The blog was the 2nd largest in its niche and lead to me making a TON of friends, one of whom I was later best man for at his wedding. I also ended up getting sweat equity in a business and learning a ton due to that blog. Moderating comments was little to no burden and even if its traffic were 10x more, moderation would still have been a trivial task.
It was a huge success in terms of ROI from my perspective. Having accounts and user-generated content on that site wasn't "betting on myself not to succeed". It enriched my life.
Unless you're living in a place that really heavily regulates the web, I don't think you need to fear having user accounts in hobby projects.
I've built dozens if not hundreds of hobby projects that had accounts. This includes a blog I ran from 2005-2017, flash games in 2010-2011, an ear-trainer for recognizing relative pitches, a couple of apps that do things with photos, half a dozen language learning apps and all kinds of other little projects. In aggregate, having user accounts brought essentially zero concerns other beyond spam management.
Taking payment is a much bigger deal, but even that is something that millions of people do online and the majority haven't even set up a business entity.
It is pretty easy to run into truble with user accounts due to privacy regulations like Europe's GDPR. This stuff is definitly not fun in a side project.
The EU is definitely one of the more difficult, less free places for building online. I haven't heard of them coming down on small side projects, though. It would be crazy, given the goals of fostering more of an entrepreneurial tech scene, but I guess it's possible.
Even in China, which is definitely hard mode for established businesses, many hobby projects stay informal and aren't really cracked down on. My first tech job was at a startup in Beijing 11 years ago and we went through some serious hassle to get an ICP and initially just targeted the foreign market due to the lower compliance overhead. That said, none of my personal sites or games were ever blocked, as far as I know of. I knew some friends that built apps on WeChat and got fairly far before formalizing.
For a small project, I would simply ignore the GDPR. The likelihood of getting fined for a tiny project is too small vs. killing it by overcomplicating it.
Where I can, I'll sidestep GDPR (and CCPA and Australian Privacy Act and whatever) problems by explicitly avoiding collecting data that might fall foul of that.
Make "user accounts" effectively anonymous. Don't collect email addresses or phone numbers or names. Just use cookies with GUIDs or autogenerated username like the default Reddit ones (without allowing people to put their own name or other PII in). Maybe let the user keep refreshing until they get a random username they don't hate, but it'll end up being something like "Abrasive-teapot-86" and never $walletName or $emailAddress. If you need to let people move accounts between devices/browsers, let them grab their GUID and call it "secret account key" and tell them never to share it. Also let them know there's no such thing as "resetting their password" and to store that secret account key if they want to be able to recover a "lost" account.
You can't _always_ get away with that. But if you can, it saves a lot of headaches.
Oh my god, I just want to say thank you for shot scraper.
I've moved over to Playwright, and one of the things I was doing with the old testing system was using it for the documentation.
Now I can do that with Playwright! - Thank you so much.
Hear, hear. My last side project was meant to be a library, but people liked the demo I built for it so much they kept pressuring me to start a hosted service. In another age, I would have been ecstatic. But nowadays, I love my job. I have a family to take care of. I don't need--as you said--a part time job. I just want to make things that are fun for me.
You also have the added security and legal responsibilities, and you are likely not getting remunerated in a way that will let you protect yourself.
One of my projects was a "squarespace" style page builder. Right away, there were nefarious users. The block editor meant that bots weren't really an issue, they couldn't figure out how to use it, but turns out humans aren't that great either. My country doesn't have safe harbor laws, so I took it offline.
Thinking now, I could put that builder back into service and just have it spit out an HTML/CSS bundle for people to self host.
That's really interesting! Could you say more about the job-like aspects of having users? Do you have advice on infrastructure that could be built to make the job easier?
I'm currently working on my first-ever side project with user accounts, and now I'm wondering what I'm in for. :-)
For me it's about the moral responsibility. If people are trusting your site with their data, you have an obligation to keep it running, and to keep it secure. This is a big responsibility! Especially since over the long-term the vast majority of projects eventually cease to exist.
In addition to user PII responsibilities, you may also be responsible for user generated content depending on where you live. Both real users and bots will inevitably submit nefarious material on your servers.
The easy solution there is to just ban European users if it's just a hobby project and your concerned about that. Probably not the solution that GDPR would prefer.
That's not as easy a solution as it appears - the GDPR isn't the only piece of personal data legislation in the world. If your strategy is to keep track of all the places that place responsibilities on you for collecting personal data and reject users from those locations then, you need to be looking at every state in the USA (Californian citizens have a consitutional right to privacy), and many countries across the world have various data protection laws.
Oh, it’s a great tip. As many of us, I’ve started a lot of projects, invested in creating auth processes, to suddenly get bored from the project and abandon it. Result: 0 users. 1 failure.
>you'll get users who you have to take responsibility for
Why's that? Can't you just provide the service as-is? I have a project that has user accounts and when people ask me for features or support, I either don't respond or say that it's not my focus.
Well said! I also learnt user moderation hell with painful way but for mobile projects If it's very necessary there's a possibility of using Anonymous logins with Firebase or Amazon AppSync as well.
Trouble is... I don't think I could build anything that I'd actually have a use for in less than 1-3 months, except for extremely ad hoc things that you can't really predict in advance, like a file convert and rename script.
I can think of 4 projects on my own, lifetime total, that I would consider ready for a "Version 1.0.0" tag, and far more that regret ever spending time on, some that required more time on top of that to disentangle myself one(Especially with hardware, where you've now got physical stuff to deal with).
The only small projects I've been happy with are the pure toys and decorations. One was a replacement for fortune, but it generates them dynamically using a MadLib style text replacement engine. Another was a candle flicker simulator.
Anything tool or infrastructure or library-like has usually become a regret, save for one multiyear megaproject, and a few things with zero reasonable alternatives.
I think the best small projects are the ones that are purely self contained, that will never have anything else depend on them, that will never be part of you "personal baggage" to maintain.
KaithemAutomation(It's on Github), which is an automation system in vaguely the same genre as HASS and OpenHAB, but aimed at minimizing SD card wear, and allowing for doing unusual things with audio.
I still do often wonder if I should just look into moving to HASS and what it would take to port all the stuff I use though....
For me it works best to start a project in such a way that it is easy to get back to. Fully expecting and embracing getting bored and leaving it gathering dust for a while.
For this to work I have docs folder with a todo.txt, architecture.txt, questions.txt and features.txt. I push it early to a private gitlab repo and use a language like TypeScript that makes it easy to come back to and make changes without fear of braking things. It won't be the first time that I get excited (again) by something and can continue on an existing project.
Yes! I keep a per-project journal file in each project's repo and it's so helpful when you end up having to take an unexpected break to bringing yourself back up to speed on why you made certain decisions or what the overall status was.
Something that also really helps is anytime I'm wrapping up a session on a project, the last thing I do before committing changes to git is to make a list of the next half dozen baby steps to complete. Without this, sometimes I'll come back to a project but only have limited time and I waste it trying to remember where I was, so a little hint from the past saying "jump in right here next time" is very handy.
+1 for a docs folder. It seems so ridiculous but I've come back to projects and can't remember where it's hosted, or how I deployed etc.
Great to have a few txt files that tell you how it all works, how you setup your server etc as it's surprising how much of your process can change over a few months/years.
One such simple project for me was https://kvak.io. A weekend crafting for a need I had and couldn't find anyone offering - a simple online notepad where I can share the note by just copying the url and the 'sharee' continues writing.
The process itself is indeed very fulfilling and joyful.
This couldn't be further away from what I really wanted. Way too much friction, lots of features and noisy UI... I'm sure it has its target audience, but it isn't for me.
I’ve created the rcmd app switcher (https://lowtechguys.com/rcmd) in 2 days, going from statically assigned hotkeys in my BetterTouchTool config to a real menu bar app with dynamically assigned hotkeys for my most used apps.
A big part of that time was spent creating the icon, and copy pasting boilerplate code from my other app for the menubar UI.
Coding the main functionality of the app took little time and it still remains one of the most fulfilling projects I’ve completed.
Of course, I have invested a lot more time since then, especially in handling edge cases with odd keyboards, only because I wanted the app to be useful to as many people as possible.
But it could have stayed the way it was as well, where a 2-day project was still solving a problem thousands of people had.
My last projects were controversial. lol. Finished it in 3?ish days. Ruby/Rails/mysql. The elevator pitch: "You place your github project on the site, you rate atleast 5 people's github project, people will view and rate your github project ". It was a fun way to view rando github projects and share feedback.
Github security reached out. Banned. All accounts locked. Creepy lawyer emails. Threats. Then i remembered we are in a closed garden now. It isn't 1998.
Then I was like oh! I will try another one. What if we allow people to automatically delete comments under 0 points on HN. I had a simple script anyone could run on their laptop. Posting was Flagged. Removed from front page in 10 minutes.
HN makes sense because votes shouldn't decide about the value of a comment. That's why the votes are hidden. You would destroy threads where people reply to your 'bad' comments.
Github on the other hand doesn't make sense at all. People participate voluntarily. Which infringement did the lawyers bring up?
This is still such a nice idea. Have you considered relaunching it with gitlab and sourcehut?
*edit: You have pitched your project differently:
"Show HN: Give and Get more GitHub stars" [1]
That's ranking manipulation. No social network can tolerate that. I would restart the project and keep the ranking on my site. People will still benefit because their projects get known. Additionally, they will receive genuine stars from the people who discovered and liked their projects.
This sounds like it about doing projects for the sake of saying they're completed?
My projects tend to be because I want something from them (explore a new toolset; have a working dish disposal; make my car able to play audio from bluetooth; not have to care about network filtering on random wifi aps; get a history of just how bad the temperature difference between rooms at home really is). They're "done" when either I have (enough of) what I want, or I lose interest and decide it doesn't matter that much anyway.
I think a lot of people suffer from guilt/shame/nagging thoughts/distraction because they start a lot of things and then lose track of them (the opposite of "mind like water") .
So this is a technique for people who start a lot of things to work in such a way that they can feel better about what they do
I think it's important to define what it means for you to "finish the project".
Is your project "finished", when you see an MVP that you can release to the world? Your project now has a minimum set of features that delivers the initial value you thought it would deliver?
Is it worthwhile to do a Show HN on it? (and risk no one clicking on it because HN receives so many submissions? :)
Is it worthwhile to release on PH? (and so many products launched in PH thesedays are... pretty much well-polished, revenue ready - if not funded etc)
What comes after you "finishing" your projects? Will you continue? or move on to something else?
For me, one of the ways to define "finishing" was to make sure that it launches with some type of payment plan. It is an MVP, but it also has monetization in it so that should anyone else wish to pay for it and use it, they can do so immediately.
Sure, not all projects are about payment and those projects are fine (which is why I said 'one of the ways'...) but if I know that this is something that I'd like to continue to work on because I enjoy it and I know it has legs, I try to find some way of generating revenue to see what the response would be.
I think for the most part I align with you regarding calling something “finished” as a project having monetization in it.
As of lately though I’ve been thinking a lot about two different definitions of “finish”, one of them being that I can use it to do some task that I want to do.
For example, I handle my finances using beancount and around that I’ve build a few projects that are finished in as much as they do what I want them to do and make managing my finances easier (import transactions from email notifications received from bank, eMacs configuration for my finances, etc.)
The second category is open source projects. I often wonder what would it take to build something that is useful to others but that doesn’t come with all the complications of a monetized products? Like, how Moodle or Drupal became Moodle and Drupal? How did they became known? Who used it first?
I want to find a tiny little problem to solve, and find a way that the people with that problem know about my solution and hopefully can benefit from it… but I don’t even know how to properly ask the question about where to start something like that… and actually finish it!
This is great. The fact that there is an incredibly low marginal cost for software projects has been on the front of my mind for a while. Compared to working on something mechanical or electrical, you can get from "fuzzy idea" to "workable-ish code" with incredibly low cost in time and money.
I've learned a lot about browsers, for example, chugging away at a little toy website[0] with a buddy. I know it is simple, but it blew me away that I could dig into webkit to see why stuff worked the way it did. We are incredibly lucky to be digging into such an accessible field.
> Compared to working on something mechanical or electrical, you can get from "fuzzy idea" to "workable-ish code" with incredibly low cost in time and money.
That’s very true but I think the fact that my day job is in software development has pushed me to work on more physical projects on weekends.
I know this will probably not be well received but there are many frameworks that are force multipliers. I see people whip out nice hobby crud sites in a few days with rails. I kind of made one with meteor once though meteor is sadly dead.
Another example is Unity and Unreal. Go to any game jam and see how amazingly productive the people are that have learned them and know where all the easy to use assets are as well.
Of course the problem with the frameworks (and game engines) is that it's a many month upfront investment to learn them and get comfortable so that when you do want to bang out a new hobby project in a weekend you can.
If you are building a mobile or web app, and not an API product, not having to write your backend is totally underrated. Hasura [0] or Supabase [1] lets you have a solid backend from a solid Postgres schema you design, which the part that arguably matters the most, and not the lossy and error prone CRUD API interface to the db. This frees up a ton of time which you can then use to improve your user experience and iterate on your idea without churning through a ton of backend code.
Having Postgres also helps a lot when you are just starting out and saves you a lot of upfront design and query planning cost you’d have with something like DynamoDB (which is pretty inflexible in ways you can query your data).
It's amazing how rich some of the puzzles are in Advent of Code. Sometimes the question is about tabular data and so is naturally suited to Excel, other times a stack-based language fits better. There's countless answers posted online to each one, each equally valid but with different tradeoffs. Great outlet for this small-project programming.
If anyone likes solving puzzles like these, I'd recommend the Zachtronics games. TIS-100 in particular was my introduction to parallelism (https://www.zachtronics.com/tis-100/).
If you did get good at this, all you’ve done is trained yourself to trust your own code over libraries. My suspicion is that experiences like this are the supervillain origin story for people with NIH syndrome.
It sounds like you're not familiar with Advent of Code. Nothing prevents you from using libraries to solve any of these puzzles. You can solve them any way you like.
I can barely finish a leetcode hard in a few hours, let alone something I would call a project. Still, this is an inspiring approach to tackling day to day work in incremental micro-projects.
Personally I find leetcode boring because it's not something that would motivate you to see finished; it doesn't have a "real" purpose, maybe trying to build something concrete (a little game, a little web app, whatever) might bring more motivation.
So far my experience with leetcode is that it is asking me over and over again to implement binary search of arrays (which is the wrong solution 95% of the time) and it wants, to charge me money for a debugger, and I have to write my own unit test framework from scratch if I want to avoid a debugger.
Everything that’s wrong with interviews, with rent seeking as the cherry on top.
I haven’t tried hard yet but I’m bracing for a shitshow.
Same for me. All these things like Project Euler leave me cold: I'd rather learn something new on the way to a tangible endpoint, even if it's a janky PoS that I never look at again and lose when I don't bother to copy it to a new hard drive.
For me, the best small side projects involve some kind of porting (between protocols, OSs or CPUs), contribution of a fix for a visible but mysterious bug, or revival of codebases in bad shape, especially when they're unfamiliar and written by others. You can learn a lot from a software engineering culture that's different from yours or small, feasible projects that allow you to understand the bits and bytes of something unfamiliar in a fun and useful way. These projects are great to develop flexibility and general problem solving intuition. And getting familiar with the 20% of an idea, a protocol, a programming language, etc' that's used 80% of the time in real-world use cases, is often enough.
I like the ethos behind this post; I've been struggling to finish projects for years, I get desmotivated, jump into another thing, don't finish it, come back after months now lost again, advance a little bit, drop it after a weekend, repeat, etc.
I will try to use the framework presented here but I'm not sure exactly how to apply it, for example the project I've been meaning to finish is what I call a very dumb compiler (parse a very simple language and emit x86_64 assembly code but without any optimizations, the most naive thing that will work).
It's hard to think how to reduce this problem to something I could do over a weekend; I have to do a lot of research, thinking and trial and error because I'm not an expert in writing parsers or anything like that.
I feel like this might only work in certain occasions.
There used to be a compilers course by Alex Aiken available online which I've found very helpful in getting started. But apparently they've limited access since. https://online.stanford.edu/courses/soe-ycscs1-compilers Maybe you can find a mirror of a previous version somewhere.
I think a compiler is a nice project because you can start with a very small language, then keep growing it and learn something along the way. Not a one-weekend project, though.
I have had this feeling a lot with my project. One thing that might work is break down the compiler itself into smaller projects. If you cant solve it all in a weekend try solving just a part of it and then calling that the project. Then move on to the next part. In the end up are building up to it without overwhelming yourself.
I was between clients for a few weeks and I wrote some apps for practicing musical scale patterns in different keys, and something to automate voice leading from chord to chord. Best three or four weeks in the last few years.
It's very simple. First reduce the requirements: ignore the melody. Then iterate through the inversions of a chord in closed position, and pick the one with the smallest "distance" from the previous chord.
Using that strategy, you can pick different chord voicing templates, like drop-2 or quartal. An even better method would be to move the "hands" up the keyboard after a tonic chord, that way you don't end up in the low registers too quickly, since jazz harmony tends to go down in 4ths a good bit.
I shipped my 'smallest' side project last week[1]. It was someone DM'ing me on Twitter trying to engage with my half-finished website that encouraged me to spend most of my weekend getting it to MVP.
It is annoying to ship something that isn't as polished as I want it to be (order fulfilment is a bit janky). But this annoyance is certainly outweighed by the joy of actually delivering something. The polish can come later is a decent amount of people start engaging with the digital project.
Meh... someone of us like the depth that comes from longer-term projects.
Don't get me wrong, I've taken art classes that taught me to appreciate smaller, shorter things. And I think it's important to take that spirit into longer-term projects. But I think there's just a lot more "small" projects these days, what with the combination of APIs, funding, hackathon culture in engineering, and prototype culture in design. The pendulum has gone all the way to the end. Which is fine too, but some of us are going to want to go the other way.
Ok, maybe. Examples would help, though. Specifically: describing the process that goes from the big dream to the smallest implementation feasible in an afternoon.
Peter Norvig creating a tiny SAT solver for sudoku stands out as one of the most sophisticated examples of a “simple” application that I know. The last time that came up several people said they use that exercise to introduce themselves to new programming languages.
Short projects are an excellent way to learn a new tool or framework. Want to learn Next.js? Looking for an excuse to try that new Golang game engine? Pick an obscenely small goal and you'll likely have more fun exploring the docs and learning the tool than getting stuck in the weeds of the myriad requirements not helping you learn that new tool.
This is delightful and well-stated. I don't think a timeline is necessary, but I do think a sense of urgency "get the prototype done as cleanly and quickly as possible" is helpful. Create an exhibition of the smallest novel component. And there you have it, progress.
A small project [1] that I use often on projects and teaching is a text-based ERD editor. Being text-based means I can write it with minimal tooling (with vim or vscode) and in git-friendly format. Since the students (and myself) requested more functions, I keep enhancing it occupationally but it is already useful since day-1 :)
I think the key motivation is being able to see the actual users (ideally also being the active user yousrelf)
I've worked on simple projects, but nothing I would consider small in the sense that I had them done in a matter of hours. But it is satisfying having a project come together in terms of completion, even more so when you reap the benefits of its use. The one that comes to mind for me would be the static site generator I built for my site, something I spent some time working on as I continued to use it, and tweak it for my needs.
I agree with this and I haven't done enough of these kind of projects but I did create this parkrun map as the one on the parkrun website was not very good.
>Make your projects small and finish them every time.
The only part I would disagree with. It's also important to know when to kill a project that's not going anywhere, where finishing won't provide any value. Yes, finish almost all your projects, but there are those few that are not worth reluctantly dragging out (especially if you've now found another tool that does the job).
I do small projects all the time. Most are modules for integration into larger ones, but I develop and publish them as standalone projects. In fact, I’m working on one right now. I’ll probably publish it tomorrow.
One of my more useful tiny projects was simple command line search until for the windows registry. It helped a lot back when I was making installers and apps that used the registry a lot.
This probably is a matter of how much you need tons of money. For me, joy and satisfaction in a project is worth more than something that makes money, but then I have a full time job that keeps me and my family comfortable.
Once all the yaks are shaved and you get around to the original goal?
Though, for myself, previous rounds of yak shaving has made it easy to start a “simple” project and usually get it finished in a reasonable amount of time since what I mostly do is write wrappers for the python C-API and my system is pretty solid at this point. Makes it easy to test out different libraries even if the end goal is to use it from a C(++) program.
Probably need to get a grip on the yaks I’m currently herding if I ever want to finish my current long term project.
If your project has user accounts, you'll get users who you have to take responsibility for. Then it's not a side-project any more, it's a part-time job.
These days I much prefer side projects which have no user accounts at all (like https://www.niche-museums.com/) or that are open source tools where the end user installs and uses the software without me having any involvement at all (like https://github.com/simonw/shot-scraper)