Hello, I turned 42 this year and I'm an active freelance engineer.
I continue to write code, thanks to the experience I've gained over more than a decade of indie hacking and my product contributions.
I've created about 10 products so far, and some have even received funding. However, solo product development remains challenging. When I first started, I often abandoned projects halfway through. But now, with my own set of rules in place, I consistently see projects through to completion.
In this edition, I've distilled these rules into 10 methods!
What are you developing?
I'm currently working on a headless CMS called 'Collections'.
Collections allows you to API your WordPress articles with a simple drag-and-drop feature. It's built entirely in TypeScript, runs on an RDBMS, and is open-source 💚.
While there are various headless CMS options available, Collections stands out by offering a seamless transition from WordPress.
Index – Collections
A headless CMS that transforms your WordPress into an API. No need to copy and paste old posts anymore.
collections.dev
Benefits of Indie Hacking
Numerous articles have extensively covered this topic, so I won't go into detail here. Just like strength training, consistency yields significant benefits over an extended period, gradually accumulating.
On the flip side, the downsides are...well, there really aren't many! If I were to mention one, it might be the time commitment. However, you could also view it as an investment in experience. As someone who has worked in a brokerage firm, it's challenging to find a more cost-effective investment than this 😆.
10 Methods
Let's get straight to it. Here are the top 10 essential factors for reaching the finish line
- Recognize developers' strengths.
- Clearly define the problems to be addressed.
- Avoid setting daily quotas.
- Establish development deadlines.
- Research competitors and emulate their methods.
- Find a reliable partner.
- Be cautious with new tech.
- Focus only on critical issues.
- Don't expect a spectacular launch.
- Make it public.
📌 1. Recognize developers' strengths
Even in an era where non-engineers can create products without coding, engineers have the advantage of sustaining product development long-term without incurring production costs.
Most services that people desire have already been developed by predecessors, making it nearly impossible to create a groundbreaking product from scratch.
Even well-funded companies always operate within budget constraints, leading to ongoing debates on whether to "pull the plug" or "invest more".
On the other hand, individuals can easily keep creating and improving their work, which is a significant advantage.
In my opinion, it's wiser to focus on developing products that can provide long-term value rather than blindly following industry trends.
📌 2. Clearly define the problems to be addressed
Once this is determined, the product becomes easier to create. For the most part
- For yourself
- For someone close to you
- For someone you don't know who has a challenge
With the third option, the potential user base is larger, making it easier to scale the product. However, it also becomes more challenging to identify common issues. During your early journey as an indie hacker, it's advisable to create a product for yourself or someone in your close circle.
You've likely heard the advice to "share your product as soon as you create it and gather feedback" at least once. While this is the right approach, receiving unintended feedback expressing that they "don't need" or "won't use" the product can be disheartening, potentially demotivating you and causing you to drop out of the race.
Therefore, in the early stages, the main goal should be to find satisfaction in what you've created.
📌 3. Avoid setting daily quotas
One strategy I've experimented with, but found to be ineffective, involves setting personal quotas, like 'write code every day' or 'complete it this week.' To be honest, it's quite simple to come up with various excuses and rationalize why I didn't take certain actions. However, when these self-imposed goals aren't achieved, it is easy to lose motivation.
So, it is much more important to keep the motivation for 'making it' high. The key to completion is to enjoy the process of creation itself 😊.
📌 4. Establish development deadlines
In contrast to not setting quotas as mentioned earlier, consider setting deadlines for development. The most significant adversaries for indie hacking are 'boredom' and 'giving up'.
No matter how high your motivation is, one of these two outcomes is bound to occur. While it's a different story for services that require extensive effort to create, when you believe that you can create something great with time, it may not always be the case. As you start noticing flaws, the fear of continuously releasing, making fixes, or worst of all, starting over becomes overwhelming. As you tinker around, you might get bored and end up not releasing at all.
So, let's release products before these pressures build up.
The goal should be to release within six months, if it takes more than a year, it should be considered too late.
📌 5. Research competitors and emulate their methods
I believe you can appreciate the importance of maintaining motivation in indie hacking. However, on the flip side, what are the moments that most often diminish motivation?
One such moment is when you initially think your idea is unique and then discover a similar service already exists 😱.
The shock of this discovery can make you feel like all the efforts you've put in so far have been instantly wiped away! Unfortunately, this often stems from insufficient preliminary research...
When a new idea strikes, and you're eager to 'develop it right away,' it's a good idea to temper that excitement a bit and start by searching on GitHub for similar software. Just because you find something similar doesn't mean there's no value in creating something new. In fact, by addressing the shortcomings of existing competitors, you can create an attractive product.
Additionally, thoroughly emulate the common elements. By identifying 2 or 3 similar projects in terms of language and structure, you can streamline concerns during implementation and prerequisite knowledge.
And thoroughly emulate the common elements. By finding 2 or 3 similar things in terms of language and structure, you can shortcut the points of concern during implementation and the prerequisite knowledge.
📌 6. Find a reliable partner
When you're developing something on your own, you might start feeling like, "Do I need this service?" or become fearful of releasing it. That's why it's important to occasionally bounce your ideas off someone else.
During these times, it's great to consult with someone who has experienced success with a product, but even fellow indie hackers work well! On the contrary, it's better to avoid seeking advice from friends or acquaintances who might find it easy to say no. Users might know what's good, but they won't fully understand until they've experienced it. Consequently, they might just point out glaring issues or say, "I won't use it" without diving into the details.
Even if you don't have someone close by to consult with, indie hackers often share common traits and interests. So, reaching out to someone for advice is unlikely to lead to hard feelings.
📌 7. Be cautious with new tech
One common challenge faced by developers is this:
The better you are in a specific field, the stronger the temptation to introduce new technologies or tools becomes. However, this can increase the learning curve and slow your progress, unless these additions are truly essential for your project. It's best to steer clear of new technologies unless they are absolutely vital for the service you're creating. With many tasks on your plate, particularly as you approach the release, taking on non-essential technologies can complicate the process.
📌 8. Focus only on critical issues
This is the second common pitfall that developers often encounter.
In the world of indie hacking, you don't incur traditional costs. However, due to the nature of this profession, the desire to perfect specifications and resolve bugs can lead to unnecessary time consumption, resulting in endless delays when trying to release a product.
In conventional software development, we typically use tools like JIRA to manage issue statuses, with labels such as highest, high, medium, low, and lowest. In contrast, indie hacking simplifies this to just two choices: critical or non-critical.
Unless it's a critical feature or a critical bug, everything else should be added to the backlog.
📌 9. Don't expect a spectacular launch
It's tough to put in a year of work only to have no one pay attention. And the creeping burnout can be intense... 😱
Think of the launch as not the goal but merely the first milestone on a long roadmap. What's crucial is to keep improving it after the launch!
Some people might be concerned that if they release their ideas incrementally, they could be copied. However, groundbreaking ideas don't come by often. The strategies that result in user growth are the truly innovative ideas. So, don't worry and keep sharing your ideas openly and freely.
📌 10. Make it public
You don't need to keep it running indefinitely. Creating just one or two articles and leaving it at that is sufficient. It can serve as a record, and if you feel like you've reached a conclusion within yourself, it can also bring a sense of accomplishment.
The important thing is to put it out into the world in a usable form!
Finally
Indie Hacking is enjoyable! It's like the foundation of our thirst for knowledge.
Let's bring a new experience to someone else!
Happy Coding!!
Top comments (0)