Business oriented thinking

• It’s common to think about the outcome before starting a project. For example: Should I build a program if a similar one already exists?
• This mindset has benefits. Knowing your end goal helps define the path to reach it. It also allows you to find niches and differentiate your product from existing ones.
• This is often how business units operate - focused on ROI, market fit, and uniqueness.
• But for open source or hobby projects, this way of thinking has downsides. Writing something similar to existing tools can still be valuable. It teaches you how things work. There’s no better way to learn than by doing and experimenting. Plus—it’s fun.
• Even when building something familiar, you might discover better approaches or features that make your version stand out.
• Too much “business thinking” can sometimes limit creativity and innovation.
• This is where R&D (Research and Development) comes into play—pushing boundaries without immediate concern for outcomes.
• “Business oriented thinking” might be short-sighted without R&D, not necessarily a good way of thinking for hobby projects.

Feedback From a Friend

While discussing the project with a friend, I realized how difficult it can be to explain its purpose and value—especially when the listener has a different mindset. The conversation unfolded like this:

Q: So what does your program actually do?

A: It’s a self-hosted link database that helps you find and organize information across the Internet.

Q: But how is that better than Google?

A: It’s not trying to compete with Google. It focuses only on searching across domains you care about. Google’s UI is cluttered, and its results are often filled with content mills, social media links, or irrelevant noise. My tool is clean, focused, and user-controlled.

Q: Can’t you just use something like Emacs’ org-mode for that?

A: Org-mode is great, but it’s local and tied to a specific environment. My project is self-hosted and accessible from any device.

Q: Why not just make it a browser extension?

A: Extensions can be blocked or removed from stores without warning. A self-hosted tool gives users more control and long-term reliability.

This exchange made something clear: not everyone values privacy, ownership, or custom workflows. For some, using Google or whatever’s convenient is “good enough.” But that’s not the audience I’m building for. The project is for people who want more control, transparency, and flexibility in how they search and manage web content.

My Experience With My Project

• It provided little to no value for the average user at first.
• I advertised it on dev forums. Initial feedback was minimal, but as I refined the vision, feedback improved.
• I focused on things users could actually use—mainly data. People can re-use my data for their own projects.
• I created well-written READMEs that highlighted practical use cases.
• I didn’t set out to achieve success. I simply felt features were missing, so I added them.
• My project is internet-oriented. One takeaway: browsers haven’t evolved much over the years. Arc Browser is one of the few to introduce meaningful UI changes.
• However, I’m more interested in functionality improvements—something often only available through extensions.
  • Instead of integrating widely used extensions into browsers, companies often remove useful features:
  • RSS support has disappeared
  • Manifest V3 limits ad blockers
  • Cached page previews are gone (e.g., in Google)
• In my project, I included useful features:
  • Direct links to Internet Archive
  • “Whois” lookups
  • “Built With” tech stack pages
  • Static analysis tools

Risks I See

• A better-funded group could easily build a similar project with better data and more reach.
• A corporation could release a similar dataset or service, making my work obsolete.

Summary

• I’ve learned a lot.
• It was fun.
• I built something that some users genuinely find valuable.
• I can re-use parts of the code in future projects.