1
2 Comments

I decided to run my production website on my own tool

I decided to run my production website using my own tool

Not as a demo, but for real usage.

The idea was simple: if it breaks, I fix it. If something feels wrong, I improve it.

The whole system is data-driven:

  • content is stored in structured tables
  • templates render everything server-side
  • routing is based on slugs
  • multilingual is built-in

Recently I improved the editor experience (tabs + undo/redo per file), and now I’m working on versioning so I can safely experiment (especially before adding AI generation).

What’s interesting is how different it feels compared to traditional CMS workflows.

It’s less about “pages” and more about “data + rendering”.

Still early, but using it in production is forcing me to make better decisions.

on April 17, 2026
  1. 1

    Nothing beats 'dogfooding' your own product. It’s the fastest way to find those annoying bugs and UX friction. I’m doing the same with AIVane—using it to automate my own Android testing and repetitive tasks. It forces you to build features that actually matter. What was the most surprising bug you found after switching your site over?

    1. 1

      Yes dogfooding is brutal but insanely valuable.
      The biggest surprise wasn’t really a “bug”, but how many SEO and rendering edge cases I had to handle once I migrated my real site.
      Before, I was using Express + Pug with full control, so a lot of things were implicit. Moving everything to my own engine forced me to:

      • rethink SSR output to be 100% crawlable
      • handle meta, structured content, and page-level SEO properly
      • deal with dynamic data + multilingual content without breaking URLs or indexing
      • optimize rendering to keep performance and consistency across pages
        Basically, I had to evolve the engine to support real production constraints, not just “it works”.
        It exposed way more than I expected — but it also made the product much stronger.
        What about you?