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
- building an open-source integration
- and eventually — refactoring documentation
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.
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.
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
From Git to Docusaurus
Git alone wasn’t enough.
Managing structure via filenames (00-, 01-) quickly broke down.
So I moved to Docusaurus.
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.
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.
