E2: Ideas and Implementation

06/16/2024, duration: 13:04

Video

Transcript

Welcome to Debugging Dan, where I share weekly my journey balancing life, a full-time job and side projects. I'm Dan, your host. Let's dive in.

The topic for today is how I do my project ideation and my project initialization and getting my ideas. So there are different approaches that people doing in the acting or solo entrepreneurs, they do have different approaches to the topic. There is a philosophy that says, hey, first think of an ID. And by thinking of an ID, you go into a certain space on Reddit or on a different community, and you try to find the problems that often are mentioned there or often occur there. And the ID that you will then have will be a solution to that problem.

The next step, when you thought of the problem or the solution that you're going to build is that you do validation. So you build a landing page, you collect email addresses there, and in the community where you found the problem and other similar communities on a similar topic, you share your landing page and share your ID. And you mention, hey, if you're interested, sign up. And that's how you can measure how good the ID resonates with the audience.

What is important there, at least in my opinion, and this is not my approach, but I ever read about it. What is important there is that the topic or the audience or crowd that you're in interested in, should also be something that resonates with you. So if you're really into podcasting, for example, you could go into a podcasting niche or because that's something that you get enthusiastic about. But if you, for example, don't have any feeling with sports, I would recommend against doing something related to sports, even though you might have found a problem you can solve. But if the topic doesn't resonate with you, at some point in time, it will get difficult to get enthusiastic about the idea about continuing because the topic doesn't really resonate with you.

So after you've collected the email addresses, I think in advance, you should set some kind of limits saying, Hey, if I get more than X email addresses, I deem this ID to be validated. And then you start creating, building the first MVP could be using a node code solution. You could be building some for yourself. You could just do the business part and have somebody else implement the ID for you. The exact process of implementation is not that important, but at least you validated the ID and you continue. And if the ID does not get validated because too little people sign up, you just continue on and you repeat the process with a different ID.

That's not really my approach. However, I did attempt it one time with Teletron. I did one time, I created a landing page and attempted to collect email addresses, but that was when I was already building the product and I was just getting close to an MVP. I tried to generate some traction related to the product, but I kind of flunked on getting the landing page out. I did collect two email addresses, but in the end, I never used those, never emailed the people saying, Hey, it's ready. Because I never felt that it was ready enough to satisfy the curiosity of those people. At some point, I might even email them, but that's more than two, two and a half years ago. So it kind of also feels weird to be emailing them.

My process is different. So I'm my own personality. My persona is I'm a pretty technical guy. I've been doing programming and developing software professionally for a job for a boss more than almost 20 years, 19 years into months for the same boss. I've worked for a nice company. And I've always been building side projects, mostly for me and only the last couple of years, I shifted to trying to also market those side projects, finding an audience instead of only building it for me.

So I do the more technical approach. At some point, I created a project from that, I derived a boilerplate, which allowed me to get started pretty quickly. Also with logging in, password reset, having the database already exposing an API, that kind of stuff. So that that's already there when I start a project. And what I tried to do is I tried to solve my own problems. So at some point, I'm busy with something and I think, Hey, it would be great, or it would be nice if I had X or Y. Then I tried to, to find a solution for that. How would I solve that? Could I productize that? Can I build a SaaS from it?

I've also built some open source stuff thinking, Hey, this is not something I can build a SaaS of, but if I do this open source, I would use it in one of my products, but I could also perhaps help other people. But I don't think any of my open source projects have been really used by other people, but at least I make them available. So that's what I do. And, in the beginning when I first started doing it, I would really do the boilerplate step. I would really start building out the product. So I would also be relatively fast with implementing and completing the solution itself.

So the problem has been solved for then. I spend a relatively large amount on getting it usable by somebody else. So building a management interface and making stuff visible, managing, things that are related to the product. I found that that might not even be necessary because I'm not always a hundred percent sure that other people will be using it. So I've also shifted to a different approach. That's what I did for the log software that I built that is able to load pages and blog posts from notion.

So what I found that when I built my products, I also need some steady content pages, like a blog or like a documentation page or other explanation, terms and conditions, for example. Um, and I figured, Hey, I don't want to build that in the project itself and deploy it when I need to change content with what I did. I did something else. I figured, Hey, I was also using, I am using notion at the time where I am using notion currently also to keep track of to-dos and project notes and similar stuff.

I figured, Hey, I might be using notion as the content engine for my blog or pages. And I just set up a product or a project that would based on the URL, get the page and it would then render that as part of the site itself. So I use a reverse proxy and carry for everything that's perfect with slash pages or slash blog. I would send to that notion project. And what I did there, I only built the solution. I did build it using the same stack as my boilerplate, but I only built a solution.

I figured I, if that's really usable, I'll fresh it out. I'll copy it over to the boilerplate and I really start doing a project there. So configuration, etc. is currently still maintained by just a JSON file on this. And it works for all the projects that I have. I'm getting into some annoyances that triggered me to say, Hey, maybe I want to build something more out of it because now if I have a new page, I need to find the ID, I need to update the JSON file and then I need to restart the project, which is annoying.

So I'm almost there at the step thinking, Hey, for me, it works. It's really beneficial. I'm still using it, which is also important. It could be that I think I'm solving a problem, but I don't, resulting in the project not being used, but I'm still using it. I'm actively using it. All my new projects also use it. That's good. And at some point, I will probably build a product out of it. Then I need to think of a name, get the domain name, because the artist wants on a subdomain, something else, since it's not public.

So that's the different approach that I'm now doing. But the most important thing is, is I try to solve problems that I encounter in my own space. And by doing that, I find that I am also, well, the idea also resonates with me. So it's something that I am passionate about because it solves a problem that I encounter. I hope to also solve that problem for other people. I can talk and explain it in passion, for example, with passion, for example.

So for me, that really helps in getting, getting passionate about something, talking about it, communicating about it. And since I'm a very technical, I can relatively easy, relatively fast, get out the product itself. So building a landing page and collecting email addresses kind of takes a day to set up, I guess, if you're doing something like that. But for me, getting something else working, I can also do that pretty, pretty fast.

So for me, that's okay. And it's, I also don't, if I build something and it doesn't turn out to be something, it's also not lost time for me because I did build it and to solve something that I myself encounter. And because I encountered myself, I will probably still be using it. And if I'm no longer using it, at least it helped me to some degree. And it also helped me gain insight in, Hey, this didn't work. And I can also learn from that when I come up with the next project or the next idea.

For me, what often is the case is that I have a lot of ideas. I'm not really a completionist. So I find it difficult when I start building something to really get it ready and done, that it's usable by someone else. And that's something that I often struggle with. Also taking then the approach that I did for the notion, blog project is then I really get to the core and then it can continue on. So I, it's very easy to determine whether it's ready or done because it works and it does what it needs to do.

And I also find it more difficult to determine when it's done, when it's also about user interface, interactivity, user experience. I'm not that good in visual stuff. So I always use one CSS library and I have very little custom CSS or also in terms of color and stuff like that. And for me, this ideation approach for a project that works for me.

So I'm definitely not saying that having a different approach, like the landing page scenario with collecting, interest and validating the ID, um, is worse or it's just different than what I do. And for me, this works. And that's how I'd, I'd share that today with you. If you have any questions or comments, just let me know it's debugging Dan on Twitter and, um, I'm interested in hearing what you think.

Thanks for tuning in to debugging Dan. If you enjoyed this episode, please subscribe and leave a review. Stay curious and see you next week.