Debugging Dan

Tech enthusiast, avid side project builder. 🚀

E21: Canceling a Project

10/27/2024, duration: 15:36

category: Podcast
/

E21: Canceling a Project

Canceling a Project

For reference, the slashdot article and the Cloudflare blog post.

In this episode of Debugging Dan, I share my decision to cancel a project I was working on called “robots against AI.” Despite being inspired by market demand and the technical challenges, I realized that the project didn’t genuinely solve my own problem, which left me with little motivation to continue. I discuss the importance of focusing on projects that truly resonate with me and align with my interests, emphasizing the benefits and risks of solving personal problems.

Stay connected! Follow me on X at @debuggingdan for the latest updates, and subscribe to my YouTube channel @debuggingdan for the podcast and other interesting videos!

My active side projects are:

  1. observalyze.com: Enhance user engagement, satisfaction, and overall experience for your application by applying Gamification
  2. teletron.me: Build personal dashboards. Visualize and make your most important information available at a glance. Your dashboards will be accessible, privacy-first, non-technical and available on multiple devices.
  3. datasthor.com: The hassle-free solution for seamless remote data storage for you or your application, making data management a breeze.
  4. supersave: Open Source: Bootstrap your project with a simple database abstraction and automatically generated REST API

Video

Transcript

In this 21st episode of Debugging Dan, I'm going to explain my reasoning on why I cancelled one of the projects I was working on. I talk about solving your own problem and why that didn't fit for me for this project. So, watch, listen and enjoy! Welcome to Debugging Dan, where I share weekly my journey, balancing life, a full-time job and side project. I'm Dan, your host. Let's dive in!

Episode 21 already, and this one is very fortunate because 21 is my wife's lucky number. So this is going to be a good one. If you're watching this via YouTube, watching video, I have been trying to update my lighting setup. It's still a work in progress. You can see it's a little bit glitchy here around my edges in my area. It's having issues with the green screen and filtering or the outlier of my face. So I'm going to look into that in the next week or so. I had help. My wife has been very, I'm very fortunate that my wife is helping me with setting up the light. Because as it turns out, I wasn't expecting that, but that's very complex. And she also helped me with setting up a new backdrop. So the previous backdrop that I generated on which the green screen is replaced was more of a steampunk vibe. But we've made it more cozy. And that's what I wanted to say as an introduction. Let's move into what I've prepared today.

I'm still remembering the hotkeys on my stream deck, so I keep looking aside. But let's move on to today's episode. So I want to talk about cancelling a project, something that I've made a decision to do this week. And I figured let's make that a topic in a podcast. And discuss what triggered it. And let's go. For the past week, I've been building on DanCuts, the video editing workflow thing that I've been working on. And progress is more slow than I expected or anticipated. And I have been putting in a lot of our way too much, basically, because it's just a proof of concept MVP, something for myself. But I really underestimated the foundation laying that is necessary of having variables and input and outputs processing between the different tasks. I am getting there, at least that's also what I thought two days ago. But the last two days, I've also been working on a lot of still foundation things. But it is making progress and it is working. And what I'm still more getting into is defining the different tasks that will help me to automate video, audio processing, even some AI transcripts, things like that. It's still fun to work on. It's still fun to work with Next.js. I watched the keynote last Thursday. Not that really exciting groundbreaking news, but it's good to see that they're still evolving the framework, improving it. And I'm especially interested in the caching. But that's mostly what I've been working on last week.

In all honesty, I still need to look at what I promised to do and to get it done five in the previous episode. Just that if you haven't watched it, because there I define what I build on in the coming two weeks. And so far, I've only built on DanCuts and some tasks are going to be dropped off. And that's what I'm talking about. Also in this week and there. Yeah, let's move on to the topic itself, canceling a project. So this week I read this tweet by Anthony; I've been following Anthony for a couple of years. He's been building cool products and he mentioned that he is building something and he needs feedback. And he figured I'm going to build it. If nobody likes it, that's OK. I'm building it for myself. I'm solving my own problem. That's a term that you often hear. And then at least my problem is solved. And it's not really time wasted. And for me, that also really resonates because that's what I also try to do since I'm doing this besides the full-time job. So that makes it more pressing, I guess, to really build something that has benefit. As a benefit, of course, if you're going full time on your side projects, then that's also the case. But for me, it feels that because I'm doing it on the side and I'm investing precious time besides work, besides family, besides other obligations, I wanted to have a benefit where in the past it was more like I built it. It's not that interesting. And then I continued on. I really tried to build things that really stay around, stick around. Not all of the projects that are currently running have that. But I try to use all of them and iterate on them based on how I use it since they all have no other customers. I'm building this for myself.

And I also responded to Anthony that that really resonate with me. And if I go into solving your own problem, there are some benefits. At least you're solving a problem, your problem. So that makes your own life easier. There's really a motivation to work on it because you're fixing your own problem. You're making your own life better, easier, and you already know more details. So you do not only have a problem, you probably also have a solution and you can. It's easier to figure out what the steps are that lead to that solution. So those are all benefits. So it's a no-brainer basically, but there are also some risks. So there's a risk of bias. You often feel that everybody must be having this problem. I'm having this problem and everybody has it. But it could be that you're the only one having that problem. There's a bias there. And if you're thinking, OK, this is my problem. I'm going to solve it. You might not be doing market research, for example. If you're even doing that, you can also build it and they will come, hopefully. And it could also be that even though other people also have that problem, you're over-optimizing it for your specific version of the problem and maybe not solving the problem for other people that have a similar problem. So those are the risks of doing it like this. The benefit that I skipped here is that it also allows you to start small.

So what Anthony did or is doing is he did not make a separate project yet, but he built his feedback tool as part of his current project that he's working on. And later on, if it has benefit, if it gains traction, he can always easily extract it into a separate project. But by building it as part of the current one, he's leaving a lot of overhead and unnecessary work behind until it is really validated, at least for his own purposes. And that's when I want to go into the project that I'm leaving behind. So I mentioned earlier that I was building robots against AI, and I got inspired by that during the holidays, where I read this article on Slashdot, where there are websites that are trying to block AI bots, and that doesn't always work because the reasons that are mentioned here, there are new AI crawlers coming out, which have a new user agent which are not normally blocked by your robots.txt unless you update it, and that's one of the most important ones. So it says, this is an example of how much the mess of the robots.txt landscape is today. And I figured, hey, I can build something for this.

So my idea was that I build a tool that automatically generates robots.txt for you. You just check a box saying, I don't want any crawlers, I don't want any search engines or specific companies, and I would be updating the list of crawlers for those specific companies, for those specific types, and you just periodically fetch the generated robots.txt from the site and it was automatically updated. And the benefit would be for me that I would get some SEO traffic, for example, because it's very easy to generate a lot of different pages for each crawler instance, explain how to use it, and at least my feeling was that there must be a lot of people having problems with this because it's on Slash.out and there are articles on it. And I was confirmed also later on when I read in September, or yeah, at the end of September, that Cloudflare was also releasing a project, a product where they would allow their web application firewall, they would allow it to block AI models. So the crawlers for the AI models, Cloudflare released a feature that would allow you to block them. And I figured, hey, that's another confirmation that at least there's a market there of people wanting to block the AI crawlers.

Not everybody might be using Cloudflare, so they might be looking for an alternative like the robots.txt. I even figured I could add a premium tier where I would have the application generate nginx rules or caddy rules, rules for the web server that would block the AI models instead of only having the robots.txt and just hoping that the bot or the crawler would adhere to the robots.txt rules. So for me, that was another confirmation. So I also put it on the get it done list. I've done this also for the coming two weeks, building on this product. But the problem is, it's not really my problem to solve. I don't have any sites that I want to keep AI crawlers away from. I don't have any news content, for example, or other content that I don't want to have scraped. So even though it is probably a good idea based on these two news articles, it's not really solving my problem.

So I don't really have an intrinsic motivation to have it done. I do love the technical challenge of gathering the image, of building the framework that would generate a custom robots.txt file, would allow you to download it periodically, features like that, but not really on the content itself. I started building it, but I haven't done any research in how I was then able to get those crawler identifiers that I would place into the robots.txt. So even though I would solve the problem technically, there was still the issue of content that I haven't even really looked in yet. So I think it's better if I spend my SEO effort, which would have a benefit by linking also to other projects that I have, is to spend it somewhere else, at Foundertooling, for example, if I decide to create a directory or something like that, I don't have the data.

And other than with this project, other active projects that I have like Datastore, like Teletron, if I keep working on things and then I think, hey, if I wanted to do this, and then I figured, hey, maybe I can make an adaptation to Teletron, for example, in terms of dashboarding or something else, or maybe I can add that to Datastore because I have the wish to store something somewhere. And by having that feedback loop or that thinking loop, I think, hey, the thing that I built there is really doing something for me because I'm figuring out ways to improve it. I'm also using it. Most of it, observer-wise, I'm not really looking into the analytics that it's collecting yet because I don't have a lot of analytics, don't have active users, and it's also pretty difficult to visualize that. But the other ones, Datastore, Teletron, I'm using.

Yeah, so having me coming back to those projects in my mind, thinking, hey, I can change that or I can change this, similar to what I'm now doing with DanCuts. I keep thinking, oh, I can use it for this. Oh, I can add this kind of task. Yeah, so that made me also realize this week that having a robots against AI is cool, is fun, and I like the name robots against AI because it's really contradicting. But I am going to cancel the domain. I'm going to abandon the idea. I haven't done a lot of work on it yet, but I figured my time is better spent elsewhere, helping myself, solving my own problems, instead of thinking, hey, maybe this would help someone else, and without doing any proper market research or having a plan or a marketing plan, just launching a new project, and then after building it, abandoning it because there is more interesting stuff to build, in my mind at least, and then not improving it or marketing it and have almost no one visiting it. I figured it's better if I just stop here, cut my losses. It was an idea, but I'm not going to continue with it.

So this is my thinking process in how I canceled robots against AI. Let me know what you think. Have you canceled any other project yourself or you're thinking of canceling? What are your considerations? Thanks for listening. Thanks for watching. Thanks for watching if you were watching. You can reach out to me on X, on Instagram. I even shared a TikTok recently. It's all DebuggingDan, except for Instagram and Thretch, where I have an underscore between Debugging and Dan because the username was already taken. And let me know 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.