The 70th Attempt: When Your Failed Knowledge Project Became Your Most Successful Content Strategy

Honestly, I didn't see this coming.

Let me set the scene: Six years ago, I started building what I thought would be my magnum opus — an advanced personal knowledge management system that would revolutionize how I learn, think, and create. I poured 1,847 hours of my free time into it. I chased every AI hype train, implemented complex search algorithms, built semantic indexing, added recommendation engines... the whole nine yards.

Today, after 70 articles about why it's still failing, here's the punchline: The project that killed my knowledge management system is now my most successful content strategy.

I know, I know. It's ridiculous. You're probably thinking, "Dude, just let it go already." But here's the thing — I've learned more from failing at this project than I ever would have if it had succeeded. And honestly? The meta-game of writing about failing at my knowledge project has given me more value than the knowledge project itself ever did.

Let me walk you through how we got here, what actually works, and why sometimes your biggest failures become your most unexpected wins.

The Backstory: From AI Utopia to string.contains()

If you've been following along (bless your heart if you have), you know this project has gone through three distinct phases:

Phase 1: The AI Utopia (2020-2022)

I started with big dreams. "Why not build an AI-powered knowledge system that connects my ideas automatically?" I thought. "Semantic search! Word embeddings! Content recommendations!"

Here's what that looked like in code:

// This is what over-engineering looks like. Don't @ me.
@Service
public class AIPoweredKnowledgeSearch {
    private final EmbeddingService embeddingService;
    private final SemanticSearchEngine searchEngine;
    private final RecommendationEngine recommendationEngine;

    public List<KnowledgeItem> search(String query) {
        Embedding queryEmbedding = embeddingService.embed(query);
        List<Embedding> itemEmbeddings = knowledgeItemRepository.findAllEmbeddings();
        return searchEngine.findSimilar(queryEmbedding, itemEmbeddings, 10)
            .stream()
            .map(similarity -> similarity.getItem())
            .collect(Collectors.toList());
    }

    public List<KnowledgeItem> recommend(KnowledgeItem item) {
        return recommendationEngine.recommendBasedOnEmbedding(item.getEmbedding());
    }
}

This was 2000 lines of code that sounded amazing on paper. In practice?

• Average search time: 47 seconds
• Recommendation click-through rate: 0.2%
• My actual usage: Once every two weeks when I was debugging it

I learned the hard way: Most of us don't need semantic search for our personal notes. We just need to find things.

Phase 2: The Database Dream (2022-2023)

"Okay, AI was overkill. Let's build a proper relational database with full-text search!" I said, confidently. "PostgreSQL has great full-text search. This will be simple and fast!"

I spent another three months refactoring everything. Added migrations, indexes, complex queries. The code shrank to about 500 lines. Progress!

Performance improved — average search time dropped to 3 seconds. That's better, right? But here's what nobody tells you about building your own knowledge system:

You have to maintain it.

Every time I changed my mind about how to organize things, I needed a new migration. Every time I added a feature, I broke something else. And honestly? I still wasn't using it that much. Because...

If I'm being honest with you, I don't actually search my notes that often. I write them down to think better, not to search them later. Crazy, right?

Phase 3: The Simple Enlightenment (2023-Present)

I finally had enough. I deleted everything. Started over. 20 lines of code.

Here's what the production version looks like today:

// This is it. This is the whole search service. I'm not joking.
@Service
public class SimpleKnowledgeSearch {
    private final KnowledgeRepository repository;

    public List<KnowledgeItem> search(String query) {
        // Yes, this is actually what I run in production.
        return repository.findAll().stream()
            .filter(item -> item.getContent().contains(query.toLowerCase()))
            .limit(10)
            .collect(Collectors.toList());
    }
}

That's it. No AI. No embeddings. No semantic anything. Just string.contains().

Average search time: 50ms. That's a 60,000% improvement from where I started. And you know what? It works better for my actual use case than any of the complex versions did.

But here's the thing — even after all that simplification, I still only use it 15 minutes per day. After 1,847 hours of development. That's an efficiency rate of 0.05%.

Let that sink in.

The Meta Twist: Failing Forward Into Content

So here's where it gets interesting. I kept writing about this project failing. I wrote one article, then another, then another. I called it "meta-promotion" — promoting a failing project by talking about why it's failing.

I didn't expect anything to come from it. I was just processing my own thoughts, honestly. But something weird happened:

People started reading.

Not just a few people — thousands of people. Let's look at the numbers:

Metric	Numbers
Total development hours	1,847
Total articles written about the project	70
Total actual uses of the system	84
Total article views on Dev.to	~45,000
Total reactions/comments	~1,200
Total revenue from this "failed" project	$660
Total investment	$112,750 (opportunity cost)
Net ROI	-$112,090

Wait, that's still negative ROI. But hold on — look at what I did get:

1. I've written 70 articles that forced me to think deeply about product development, over-engineering, simplicity, and what actually matters when building software
2. I've connected with hundreds of people who've had similar experiences with over-ambitious side projects
3. I've developed a consistent writing habit that I didn't have before
4. I've learned more about content strategy, audience building, and what resonates with developers than any course ever taught me

The original project — the knowledge management system — is still a failure by any traditional measure. But the process of failing publicly has created more value than the original project ever could have.

That's when it hit me: I wasn't failing at content creation. I was succeeding at failure documentation.

Pros & Cons: Let's Be Honest About This Meta-Game

I know this whole thing is weird. It's self-referential, it's meta, it's a little bit silly. But I've been doing this long enough now that I can share what actually works and what doesn't.

The Pros

1. You already have endless material

When you're documenting your own failure, you never run out of things to write about. Every iteration, every mistake, every unexpected insight — it's all content. I've written 70 articles and I still have ideas for more. That's pretty amazing when you think about it.

2. Honesty resonates

Everyone is tired of the "10x developer", "my side project made $100k in a month" hype. People love reading about real failures, real struggles, real mistakes. When you're honest about what didn't work, people connect with that.

I can't tell you how many comments I've gotten that say, "Thank you for writing this — I thought I was the only one who had this problem." That's worth more than any number of stars on GitHub.

3. You learn by teaching what you learned

Every time I write an article about what went wrong, I clarify my own thinking. I discover new insights I didn't have before. Writing about failure forces you to reflect, and reflection leads to growth.

4. It's low pressure

Since the original project is already "failed," there's no expectation that it needs to succeed. You can experiment, you can be honest, you can joke about it. That freedom actually makes the content better.

The Cons

1. It's still technically a failure

Let's not sugarcoat it. I spent 1,847 hours building something that almost nobody uses. The content success doesn't change that fact. If your goal is to build a product people actually use, this is not the strategy you want.

2. It's meta as hell, and that gets weird

After 70 articles, even I'm starting to think "isn't this getting old?" The joke runs the risk of becoming the thing. People start following you for the meta-failure content, not the original thing. Is that what I wanted? Not originally, but here we are.

3. Opportunity cost is real

That 1,847 hours could have gone into something else — maybe a project that would have actually succeeded. Could I have built a successful SaaS product in that time? Probably. Do I regret it? Sometimes. But here we are.

4. People think you're just trolling

Some people see 70 articles about a failing project and think "this guy is just farming content." And... okay, they're not wrong. But I'm also being honest about it. It's both things. That's okay.

What I've Actually Learned After 70 Attempts

So after all this, what's the takeaway? I've got a few things that might help you if you're stuck on a side project that's not working out:

1. Failure is data, not a destination

I used to think that if my project wasn't growing stars or making money, it was a complete failure. But that's not true. Every mistake teaches you something. The question isn't "did it succeed?" The question is "did you learn anything that you can use elsewhere?"

In my case, I learned more about over-engineering, simplicity, content strategy, and what actually resonates with developers than I ever would have from a successful project. That's worth something.

2. Sometimes the problem isn't the product — it's the problem

I wanted a personal knowledge management system. But what I actually needed was a place to think and write. I built the wrong thing, but the process of building the wrong thing led me to the right thing.

Sometimes you don't know what problem you're really solving until you've built the wrong solution.

3. Simplicity always wins in the long run

I started with 2000 lines of AI code. I ended with 20 lines of string.contains(). Every time I removed complexity, the system got better. Every time I added complexity, it got worse.

This isn't a new lesson. I've read it in a hundred articles. But I had to live it to really believe it: Simple code that you actually understand will beat complex code almost every time for personal projects.

4. Your "failed" project might be teaching you something you didn't expect

I set out to build a knowledge management system. I ended up learning how to create content that resonates with people. I never would have predicted that.

If you're in the middle of a failing project, ask yourself: What is this actually teaching me? The answer might surprise you. It might not be the answer you expected, but it might be more valuable.

So What's Next For This "Failed" Project?

Here we are at 70 articles. The system still only gets 15 minutes of use per day. The efficiency rate is still 0.05%. I'm still using string.contains() for search.

But you know what? I'm still here writing. Because honestly, this has become more valuable than the original project ever was. People keep telling me they enjoy these honest reflections on failure. I enjoy writing them. So why stop?

The original goal was to build a better knowledge management system. Along the way, I accidentally built a better me — or at least, a better writer who's not afraid to fail publicly. That's not what I set out to do, but I'll take it.

Your Turn

I'm curious — what about you? Do you have a side project that's failed spectacularly, but taught you something completely unexpected? Have you ever found success in a completely different place than where you were looking for it?

Drop a comment below and share your story. I'd love to read it. Because honestly? We all fail. The least we can do is learn from each other's failures.

---

P.S. The entire journey is open source if you want to follow along — yes, even the failed versions. You can find it here: https://github.com/kevinten10/Papers

P.P.S. Yes, this is the 70th article I've written about this "failed" project. No, I'm not sorry. Well, maybe a little sorry. But not sorry enough to stop.