> ## Content Index > Fetch the complete content index at: https://zahradnik.io/llms.txt > Use this file to discover other available public pages before exploring further. # How I Refactored and Standardized Product Documentation - URL: https://zahradnik.io/how-i-refactored-and-standardized-product-documentation/ - Published: 2026-05-03T15:00:02.000Z - Updated: 2026-05-03T15:03:22.000Z - Author: Vladimír Záhradník - Tags: Eledo, Documentation, Systems thinking, Docusaurus, Git ## Product Background My client runs his SaaS business almost entirely on tools he built himself: - a custom issue tracker - a custom Kanban board - a custom accounting system - a custom CMS powering all documentation It’s impressive. He owns his entire stack — and as a sovereign builder, I resonate with that deeply. But systems optimized for one person rarely scale well to others. That’s where friction begins. --- ## The Hidden Cost of Founder-Centric Tools Two issues became immediately clear: ### 1\. Capacity vs production quality As a solo developer, he simply doesn’t have the bandwidth to bring every tool to production-grade polish. They work — but they live somewhere between alpha and beta. That’s fine internally. But it creates friction for collaborators. --- ### 2\. Perfect for him — imperfect for others These tools were designed around his mental model. He understands them instantly. I don’t. For me, they introduce friction. Example: - I refused to use his time tracker daily - I logged time in my own system - then mirrored data monthly And gradually, I started adapting more parts of the workflow to something that works for both of us. This led to: - creating a [GitHub organization](https://github.com/eledo-online/?ref=zahradnik.io) - building an [open-source integration](https://github.com/eledo-online/n8n-nodes-eledo?ref=zahradnik.io) - and eventually — refactoring [documentation](https://github.com/eledo-online/docs?ref=zahradnik.io) --- ## Why the CMS Had to Go (as a primary system) The CMS worked. But it constrained thinking. Problems I ran into: - drafts and public articles mixed in one tree - slow content creation workflow - lack of clear audit history - no approvals - no staging environment - difficult restructuring - high friction for experimentation Most importantly: > The tool started shaping decisions. That’s always a red flag. ![Screenshot of custom CMS interface with document tree and editor in an internal tool](https://storage.ghost.io/c/98/55/9855d37b-ac20-4dfa-abf2-b089f6222e9f/content/images/2026/05/cms.png) Original CMS — functional, but shaping decisions instead of supporting them --- ## The Shift: Git as the Source of Truth I started by mirroring documentation into Git. At first: - same structure - minimal changes - assets moved into repository Then I started building forward — not just copying. --- ## Documentation as a System (Not Files) While writing documentation for the n8n integration, I changed my approach: I wasn’t writing docs. I was designing a **template system**. The result: - reusable structure - platform-specific variations (n8n, Make, Zapier) - consistent mental model Now every new integration: - starts from a scaffold - adapts terminology - reuses structure That alone saved significant time. ![Side-by-side navigation trees for Make, n8n, and Zapier showing consistent documentation structure](https://storage.ghost.io/c/98/55/9855d37b-ac20-4dfa-abf2-b089f6222e9f/content/images/2026/05/Template.png) One pattern across integrations — adapted language, shared structure --- ## Target Audience Redesign Originally, documentation was written: > by a developer, for developers That’s a common trap. I redefined it: ### Primary audience Non-technical users exploring PDF generation If they get stuck: → they leave --- ### Secondary audience Technical integrators and consultants They need depth — but not at the cost of clarity. --- ### Constraint Documentation must remain technically accurate. --- The result: - layered structure - clear guidance - advanced sections for power users - hints, tips, warnings ![Documentation page showing “Source Mode” with an info box indicating advanced feature for technical users](https://storage.ghost.io/c/98/55/9855d37b-ac20-4dfa-abf2-b089f6222e9f/content/images/2026/05/image.png) Clear boundaries — advanced sections are visible, but not intrusive --- ## From Git to Docusaurus Git alone wasn’t enough. Managing structure via filenames (00-, 01-) quickly broke down. So I moved to [Docusaurus](https://docusaurus.io/docs?ref=zahradnik.io). It gave me: - Markdown-based system - automatic navigation - configurable structure - validation of references (huge win) Later: - migrated to MDX - added custom components - used admonitions for clarity --- ## Current State After several months: - documentation lives in Git - full version control (PRs, history, signatures) - automated builds via GitHub Pages - versioning introduced (1.0.0) - local staging available One important detail: > SEO disabled for developer docs This was a concern — solved with a single flag. ![GitHub repository README for documentation project with badges, versioning, and MIT license](https://storage.ghost.io/c/98/55/9855d37b-ac20-4dfa-abf2-b089f6222e9f/content/images/2026/05/image-1.png) Documentation treated as code — versioned, reviewed, and released --- ## The Remaining Problem The CMS still exists. Which creates a mismatch: - Git = source of truth - CMS = public interface Currently: → manual synchronization Acceptable short-term. Not scalable. --- ## Next Step I will build a custom sync tool: - Markdown → CMS format - automatic updates - full pipeline Once done, I’ll document that process as well. --- ## Final Insight This wasn’t about documentation. It was about: > **removing friction from collaboration by redesigning the system** Tools changed. Structure changed. Process changed. But the goal stayed the same: > make the system work not just for the founder — but for everyone involved.