Nine hundred to three

As we pass 450 articles in two languages in the 360Learning Knowledge Base, I thought it would be a good time to share with other small tech teams that maintaining external documentation doesn’t have to be expensive or complex. This includes updating it at the same pace as the product, handling documentation requests within one business day, and translating to another language within two business days. With just a few tools and some dedicated time, it is possible for a team of three tech writers to maintain an entire documentation in two languages.

Our toolbox contains two basic items: documentation hosting via Zendesk and translation via Transifex. We then use a docs-as-code engine to automate the publishing workflow, and Claude Code as our assistant. This amounts to less than 200€/user/month.

Instant release documentation

The product ships fifteen new features every three weeks. The documentation updates are instantly visible on the same day as the release.

We focus on how-to guides, but deviate when there’s evidence we can deflect support tickets easily.

We used to rely on the publication scheduling feature from Zendesk, but we found that a branch-based system gives more control, and a better overview of all the changes linked to a release.

On the day after the previous product version is released, we create a git branch for the next release, and all documentation updates related to a feature are pushed as a single commit. This allows us to have one commit per feature for traceability. This also lets us share the upcoming changes with product managers, and any other team.

When the new product version is released on prod, we merge the release branch to the main branch, which publishes to Zendesk.

Nine hours turnaround

Anyone can flag something missing or incorrect in the documentation.

We don’t impose any format for the request. We’re interested in any feedback, and we realized that forcing a specific format wasn’t accelerating the turnaround.

We want those requests to be about content, not broken links, inconsistencies, or misunderstandings. So, we built a series of automated checks:

• checking if external links resolve, with lychee
• checking if internal links resolve, with a custom script
• checking small syntax rules, with vale
• checking readability, with the Flesch-Kincaid Grade Level
• checking interface learnability, with a custom script

Checks are run instantly on the updated articles, and weekly on the entire documentation. They don’t block article publication, and can be addressed asynchronously.

When someone creates a request, we feed that request to Claude Code, then review the suggested changes. Since we impose a high readability and interface learnability score, they’re usually straightforward to review.

We also have a strict policy of “no screenshot”. The downside is lower engagement. The upside is that we can update articles in a few seconds, keep everything searchable, and translate faster. For readers who want to find answers to a specific question fast, the upsides outweigh the downsides.

48 hours translation delay

Every update to the documentation must also be translated into French. This is about 10,000 words per month. We handle this by first running an LLM translation batch, then reviewing manually.

The LLM-based translation script pulls the untranslated strings from Transifex, translates them, then pushes them back to Transifex. The translation step fetches the product glossary dynamically from the product code, and applies our styleguide. This lets us have a good quality first pass, without manually maintaining a glossary.

The manual review is done through a custom frontend app, replacing Transifex’s native UI. I may describe its details in another post, but here’s the general idea that now makes reviewing sessions actually pleasant:

• Full context. The source and translated article are displayed side by side in their entirety. This is a major pain point in most translation interfaces.
• Keyboard-only. No mouse. Writing text and controlling the app happen as a single workflow.
• Snapping speed. No tiny loading, waiting for confirmation, or extra actions to change context. Everything happens seamlessly, and is automatically sequenced.

We have two French speakers in the team, to avoid bottlenecks.

That’s it! We think keeping a tight scope and refusing specialization within the team are two important factors for team resilience and output quality.

If you’ve had to read our documentation, I hope you have found it helpful, clear, and generally amazing. If you’ve used 360Learning but never had to look for help, then I credit the awesome team that I work with for designing a great piece of software.

And if you’ve never tried 360Learning, reach out!