When To Kill Your Product Idea | Behind The Product

I know it sounds harsh but is your idea worthless? It depends. It's the initial fuel and motivation to start building. You shouldn't fall in love with it though. Instead, fall in love with the people and the problem you're solving. Can't bring yourself to do that? Your idea might've been worthless after all!

I sat with Heiki Riesenkampf of Acapela (https://acape.la/) for the first time to have an honest talk about business. We discussed why Welder didn't take off, his competing with Slack, or the difference between US and European engineers.

We’ve gone through the most popular ones for Elixir (LiveView), Ruby (HotWire), PHP (LiveWire), and Python (Unicorn, Reactor, Sockpuppet) and also some language-independent choices (htmx).

Server-side rendering is getting better with modern libraries, you can have just a single codebase (let's say in Django or Rails) and add similar interactivity that you would get with frameworks like React! 

We discussed our experience with unproductive days and how we feel when they happen. We also talked about how rituals and habits help us to stay productive and get back to being productive after unproductivity happens.

Should you keep going or is time to let it go? There is no simple answer, but there are some variables to take into account when thinking about killing your idea. Oh, and context matters. More than anything. 

Why does working in weekly sprints work for a small bootstrap product team like ours? There are multiple reasons. We tried the same approach before but it had its flaws. A lot of them. We learned our lessons the hard way and want to share them with you.

We explored many different approaches to see when to use no-code tools. And also when not since the tradeoffs might be huge. We learned that no-code is a no-brainer for validation and MVP building if you are a solo non-technical founder. It's also handy when you want to do something outside of the core competency of your company and you don't want to spend your development budget on these efforts. Let's say connecting your product to some analytics or building an MVP to validate a new direction of your company.  But if your entire software business is based on no-code, you need to make sure that it can be built with it. You'll have to adjust your product expectations to fit the 'green path' that the no-code tools provide.

We discussed why it's so important to correctly assess the technical complexity of a product. Especially for bootstrapped companies. There’s always going to be more edge cases than you’d think initially but your MVP should be simple and not buggy. One of our earlier products didn’t even reach the MVP phase because we underestimated this phenomenon. And we did the same mistake with Welder. Now we have to face this problem again. Too many bugs, drawbacks, and unexpected edge cases. Too little development manpower to fix all of these in a reasonable timeframe. Your customers won’t always follow the green path and your product should not fall apart and disappoint them because of that.

One post on IndieHackers made us think about when is the right time to take a break from building your business. We discussed our own experience with taking a break after 4 years of building a business. It gave us time to recharge and think about what we learned. It refilled our creativity and energy so we could get back into building.