How I build things
I recently received an email from a reader of my blog asking about my process for building things.
I was wondering if you'd be willing to share your workflow for building products. At big companies, we'd usually do a lot of planning with diagrams, documentation, etc before building anything. I tend to get stuck in analysis paralysis when it comes to building a new products. Seeing how you've built some nice tools like Bear Blog, I wanted to hear from you personally.
I've built a lot of things over the past 10 years. Mostly to satisfy my own curiosity, with a few of them becoming actual products that fund the rest of my tinkering.
My approach to building products is more akin to a gardener than to a product developer. I play around with ideas, follow interesting threads, and see where the path takes me. I keep a Trello board of random ideas that I'd like to play with later. These ideas sit and germinate in the back of my mind for weeks or even months. Then, when I have some free time I pull up the Trello board and select an idea I'm particularly interested in and build a prototype.
The key to being a good thing builder, in my experience, is to always try and ship something. This just means that someone can pick it up, and potentially find it useful. It doesn't have to have user authentication, analytics, or even a landing page. It just needs to be something.
If the idea is a good one then I may expand on it. But most of my projects are for my own use, or just to satisfy my curiosity. You can see a few small projects I have been tinkering with recently at https://herm.app. These are all useful or interesting to me, but none of them are commercially useful (yet).
Every now and then a prototype gains traction and turns into an actual product. This is when I give it my full focus. Out of the dozens of projects I've built over the years, this has only happened a handful of times (you're reading this post on a blogging platform that is a product of this process). In these cases I actually have a hard time not working on the project. The thrill of the build takes over and I need to actively ensure I put down the code at the end of each day.
It's really exciting when something you build starts creating value (and it also feels good when people want to pay you money for it).
As for the day-to-day of building things, I tend to wing it in the early stages. This is an experimental phase and so I can't set meaningful tasks for myself, otherwise my task list would look like this:
TODO:
1. Explore idea
2. ???
But once something has taken form, then it makes sense to create a TODO list. For smaller projects this is just a note in a text file, but once it becomes a large project then I move it over to Trello so I can visualise, categorise, and prioritise tasks.
As for staying motivated during the build process, while I don't have anything prescriptive I did write a post on what works for me.
In a nutshell: I build things that I find interesting. I'm just glad other people find them interesting as well.