Build for you
Being able to build software products is an in demand and empowering skill. Every day you probably see numerous inefficiencies you want to address with this new power. Unfortunately, time is pretty limited so you can't address everything.
When I'm starting out a new side project I always make sure that I'm "building for me". After all, when you're building software you're the first user.
Building for yourself is an important consideration because it helps you evaluate need and the over all efficiency gain you might see.
Addressing pain points
Tasks that are frequent or painful in your day to day life are always viable candidates for a new project. Whenever you can save yourself a bit of time to do something you enjoy more (family, skiing, anything) that's an amazing thing!
If you're seeing a pain point regularly in your life this means there's a decent chance that others experience it as well. This means that your tool can have a higher impact. These are potential users, too.
Make sure it's really painful
It’s important to note that it’s better to automate things that add up to a lot of time or discomfort each year. Optimizing infrequent tasks that are low friction won’t result in a drastic improvement.
They can even turn into a time sink. Not all rabbit holes are worth exploring.
When you build for you, you're going to be dogfooding from very early on in the development process. Dogfooding is important for a few reasons. Firstly, you will find mission critical bugs and workflow issues that you can iteratively address. It will also provide motivation for you to fix some of those issues you might ignore otherwise.
Most importantly, dogfooding helps you prioritize between bug fixes and new features. If you're using a piece of software on a regular basis, you will know which bugs are show stoppers and which features are must haves.
I've never known a test suite that caught all bugs. They're inevitable. If you're continually deploying code to something you use on a day in, day out basis you're instantly QA-ing every build very soon after it ships. That means any bugs or regressions that are introduced will be found quickly.
You'll also be motivated to fix them quickly.
Keeping with it
All projects, whether it's an OSS library or a product, take time to evolve and mature. You have to be in it for the long haul. Very few see overnight success, but some projects need to grow into an inflection point that can take weeks, months and even years.
If you're finding value in something that you're building while you're building it you'll be continually iterating. Projects need momentum, and a small bugfix each week has high long term value.
When deciding between projects, make sure you choose something interesting. Whether that means solving a problem that inspires you or using a tech stack that will keep you coming back for more.
It's easy to keep working on a project when it doesn't feel burdensome.
Writing software should be about having fun, being creative, and improving lives. If you're your own first user, by building for you, you'll have a head start.
Happy hacking <3