The 69th Attempt: When Your Knowledge Management System Becomes a Content Factory (But You're The Only Customer)

Honestly, I didn't plan for this. When I started building Papers — my "advanced" personal knowledge management system — I had grand visions: AI-powered recommendations, semantic search that actually understood what I meant, a system that would organize my entire digital life and make me smarter just by looking at it.

Six years and 1,847 hours of development later... well, let's just say things didn't go according to plan. But honestly? I think I ended up with something more interesting than what I originally set out to build.

Let me back up. What even is Papers?

Papers is my personal knowledge base — a Spring Boot application that stores all my technical notes, articles, and random thoughts. The basic idea is simple: save everything you learn, so you can find it again later. That makes sense, right? Everyone forgets things.

Here's what it looks like at its core these days. After about 2000 iterations of simplification:

@RestController
@RequestMapping("/api/knowledge")
public class KnowledgeController {

    private final KnowledgeRepository repository;
    private final SimpleSearchService searchService;

    public KnowledgeController(KnowledgeRepository repository, SimpleSearchService searchService) {
        this.repository = repository;
        this.searchService = searchService;
    }

    @GetMapping("/search")
    public List<KnowledgeItem> search(@RequestParam String query) {
        // I learned the hard way: simple text search beats complex AI
        return searchService.simpleSearch(query);
    }

    @PostMapping
    public KnowledgeItem save(@RequestBody KnowledgeItem item) {
        item.setCreatedAt(Instant.now());
        return repository.save(item);
    }
}

See that? No fancy embeddings. No neural networks. Just... simple text search.

And that's after going through three full architectural overhauls. Let me walk you through the madness.

The Three Stages of Knowledge Management Grief

So here's the thing about building your own knowledge management system: you start idealistic, and you end up... well, here. Let me show you the journey.

Stage 1: The AI Utopia (First 6 months)

When I started, I was convinced that AI was the answer. We had all these cool new embedding models, semantic search, transformers that could "understand" your content. Why would anyone use boring old text search when AI can do better?

I spent three months building a full AI pipeline:

• Generate embeddings for every article
• Store vectors in a specialized vector database
• Use cosine similarity to find "related" content
• Build a recommendation engine that suggested what I should read next

It sounded amazing on paper. In practice? Let me show you what the search looked like back then:

// This is what passed for "AI-powered search" in my first version
public List<SearchResult> aiSearch(String query) {
    // Generate embedding for query
    float[] queryEmbedding = embeddingModel.embed(query);

    // Find nearest neighbors
    List<ScoredItem> results = vectorDatabase.findNearest(queryEmbedding, 20);

    // This took 47 SECONDS on my 2000+ article database. 47. Seconds.
    return results.stream()
            .map(this::convertToSearchResult)
            .collect(Collectors.toList());
}

Yeah. Forty-seven seconds. For a search query. On a database smaller than most people's photo collections.

And the results? They were... fine? Sometimes it got what I meant. But most of the time, I just wanted to find that one article I wrote six months ago with "docker compose memory" in the title. Semantic search would give me twenty articles vaguely related to containers, none of which were the one I actually needed.

I learned the hard way: when you're searching for something specific you know you wrote, exact word matching beats semantic understanding every single time.

Stage 2: The Database Dream (Year 2)

Okay, so AI didn't work out. No problem, I thought. Let's just use a proper database with full-text search indexes. That's what all the smart people recommend anyway.

I migrated everything to PostgreSQL with GIN indexes for full-text search. Got search time down from 47 seconds to about 300ms. That's a huge improvement, right?

And it was! For a while. But then I started overcomplicating that. I added tags, categories, metadata extraction, custom scoring algorithms... pretty soon I had 2000 lines of complex query building code that I didn't really understand anymore.

The funny part? I was still just searching for articles by keywords. All that complexity wasn't making my results better. It was just making the system harder to maintain and slower to change.

Stage 3: The Simple Enlightenment (Year 3 onwards)

One day I was fed up. I deleted 1950 lines of code and wrote this instead:

@Service
public class SimpleSearchService {

    private final List<KnowledgeItem> allItems;

    public SimpleSearchService(List<KnowledgeItem> allItems) {
        this.allItems = allItems;
    }

    public List<KnowledgeItem> simpleSearch(String query) {
        String lowerQuery = query.toLowerCase();

        return allItems.stream()
                .filter(item -> item.getContent().toLowerCase().contains(lowerQuery))
                .sorted(Comparator.comparing(item -> 
                    // Prioritize title matches over content matches
                    item.getTitle().toLowerCase().contains(lowerQuery) ? 0 : 1
                ))
                .limit(50)
                .collect(Collectors.toList());
    }
}

That's it. Twenty lines of code.

Want to guess the search time? Around 50ms. Fifty. Milliseconds. On my 2847 article collection. That's 60 times faster than the AI version. 6x faster than the PostgreSQL full-text search version.

And you know what? It works better. Because when I search for "docker compose memory", it gives me exactly the articles that have those words in them. Which is 99% of what I actually want.

So What Have We Learned Here?

Honestly, this whole project has been one long lesson in humility. Let me break down the pros and cons honestly, because that's what nobody does anymore.

The Pros (Yes, there actually are some!)

1. It's my system, built my way

I don't have to work around somebody else's organizational philosophy. I don't have to pay a monthly subscription for features I'll never use. It just does what I need, and nothing more.

1. I learned so much from building it wrong

You can read all the blog posts you want about "simple is better", but you don't really understand until you've spent 6 months building something complex that fails. I've learned more about performance, architecture, and user-centered design from this failed project than I did from most of my day job projects.

1. It's actually pretty reliable now

After all that simplification, what's left is rock solid. It's just Spring Boot, PostgreSQL for storage, and twenty lines of search code. There's not much to break. It's been running in production on my VPS for three years with basically zero issues.

1. It became a content factory instead of a knowledge base

Here's the unexpected part: by writing 69 articles about building this failed knowledge management system, I've actually created more content than I've ever organized. The side effect became the main product. That's weird, right? But here we are.

The Cons (Let's be completely honest here)

1. The efficiency ratio is absolutely brutal

Let's do the math:

• Total development time: 1,847 hours
• Actual daily usage: ~15 minutes per day
• Efficiency rate: 0.05%

That means for every 2000 hours I put in, I get one hour of actual use out of it. That's... not great. Is that even a word? "Brutal" doesn't do it justice.

1. I'm the only user

I've had 69 articles published about this project. I've had maybe a dozen people star it on GitHub. I've had zero people actually use it for their own knowledge base. That's okay — I didn't build it for anyone else — but it does mean the ROI is negative \$112,090 and counting.

1. Most of the value is in the writing, not the software

The funny thing is, the actual software doesn't get used much, but writing about the process has been incredibly valuable for me. I've clarified my thinking, I've practiced writing technical content, I've learned how to explain complex ideas simply. So the project failed as software, but succeeded as a writing exercise. That's a weird kind of success, but I'll take it.

1. Search is still bad, actually

Wait, what? Yeah. Even after all that optimization, simple text search is still bad at finding things when you don't remember the exact words you used. That's the problem with knowledge management — you often forget what you called something when you wrote it. So you still end up scrolling through pages of results sometimes.

But here's the thing: so does everyone else. Every knowledge management system I've tried has this problem. I don't feel so bad about it anymore.

Would I Do It Again?

That's the question everyone asks, right? Would you build this again knowing what you know now?

Honestly... probably. Because I didn't end up with what I expected, but I did end up with something interesting. I learned more than I would have if I'd just used Notion or Obsidian or whatever everyone else uses. And the writing process has been unexpectedly rewarding.

But I wouldn't recommend it to most people. If you actually need a working knowledge management system today, just use one of the existing ones. Don't spend six years building your own. That's what I wish someone had told me six years ago.

So Where Does This Go From Here?

I'm at the 69th attempt now. Sixty-nine articles about building a knowledge management system that almost nobody uses. That's kind of amazing when you think about it. It's become a tradition at this point. I'll probably keep writing them.

I've accepted that Papers will never be the productivity tool I originally envisioned. It's become something else — a personal experiment in persistence, in learning in public, in turning failure into content. And honestly? That's enough for me.

What About You?

I'm curious — do you have a passion project that completely failed to deliver on its original promise, but ended up giving you something else valuable? Have you also spent years building something that you're the only user of? Did you also learn more from failure than you ever could have from success?

Drop a comment below and let me know. I'd love to hear your stories.

Papers is open source if you want to poke around — remember, it's more of an experiment than a production-ready tool. But if you're curious, you can find it here on GitHub.