🐶 Dogfooding LeafWiki – Why Using Your Own Tool Matters

#devjournal #webdev #opensource #selfhosted

"Eat your own dog food."

In other words: Use your own product.

That’s exactly what I did with LeafWiki – the Markdown-based wiki I’m building. I started writing its own public documentation using LeafWiki itself.

And as expected, a few things broke along the way. Which is great – because that's exactly the point of dogfooding.

You think your tool works – until you actually rely on it.

Real usage surfaces issues you'd never catch while just developing.

🧭 What is LeafWiki?

Quick version:

A Markdown-based wiki with a tree structure
Content lives as .md files in folders
No database, no cloud, no lock-in
Just a single Go binary you can run anywhere

The idea is to give devs and small teams a simple, self-hosted alternative to tools like Confluence or Wiki.js, without all the setup overhead.

🧑‍💻 Why I built it

I’ve used a lot of wikis – and honestly, most of them felt like too much.

Complex setup, clunky UI, full DB stack – or just... slow.

I wanted something that:

looks clean
runs fast
stores everything in plain Markdown
doesn’t tie me to a platform

Not trying to replace Confluence or Wiki.js completely – but for small teams, dev environments, or side projects, LeafWiki might be all you need.

So I built it in Go, made it a single binary, and made sure it works on everything from servers to Raspberry Pis.

⚙️ What LeafWiki can do (v0.4.3)

🌐 Public Pages
🔍 Full-Text Search (via SQLite)
📂 Tree Navigation
✍️ Markdown Editing with CodeMirror (Split View, auto-scroll)
🎨 Syntax Highlighting
📱 Mobile-Optimized UI
👥 Simple Role System (Admin / Editor)
📤 Asset Upload & File Management
🧱 No DB – everything lives in the file system

🧩 What’s next?

Right now, LeafWiki manages its page structure using a separate tree.json file.

That seemed fine at first – but after using the tool myself, I realized:

It’s not ideal. Kind of a conceptual misstep, really.

It works, but it breaks down if you want to:

version everything in Git
drop in a folder of Markdown files
keep structure and metadata in sync

So I will switch to Frontmatter inside the .md files.

That way, the structure becomes part of the content. It’s more portable, Git-friendly, and just cleaner overall.

Took me a while to admit it – but hey, dogfooding doesn’t lie.

It’s the best way to figure out what actually holds up under real-world usage.

Also planned:

Server-side rendering for public docs

🧪 What I found while dogfooding

While writing LeafWiki’s docs inside LeafWiki, I ran into a few rough spots – most of which are already fixed for the upcoming v0.4.4 (dropping June 29):

❌ Bugs I ran into:

Slugs saved too early

→ If you typed fast and hit Enter, the slug wasn’t ready (roadma instead of roadmap).
Editor jumped to top after save

→ Classic React remount issue – annoying, but fixed.
Scroll position lost when navigating back

→ React router + scrollable divs = not friends by default.
Edits lost after token refresh

→ Access token expired silently; the refreshed token didn’t apply to the save.

Losing edits like that was especially frustrating – and definitely something I needed to fix.

✅ What dogfooding really taught me

Dogfooding is more than just testing – it forces you to experience the product like a real user.

Things that seemed fine during development became frustrating during actual writing.

Suddenly, a scroll jump broke focus.

Suddenly, saving wasn’t just a button – it had consequences.

Dogfooding gave me honest, immediate feedback.

It highlighted weak spots and helped me prioritize what really matters.

If you’re building a dev tool and haven’t used it for actual work yet: Do it.

It’s uncomfortable, but it makes everything better.

📣 What’s next?

I’m putting the finishing touches on the public docs, which will go live soon.

In the meantime:

🔗 github.com/perber/leafwiki
Try it out. It’s free, open source, and zero-setup.
Bug reports, feedback, or just saying hi – all welcome.

⚠️ Heads up:

LeafWiki is still very much in active development.

It works, and I use it daily – but if you're planning to use it in > production, be aware that things may still shift a bit over the > next few releases.

That said, early feedback is incredibly helpful right now.

Let me know what you think – or better yet:

Try writing your own docs with it. That’s how it gets better.