Technical writing for complex software products
I’m Lena Ansorge, a technical writer and documentation systems consultant helping software teams turn complex product knowledge into clear, maintainable documentation.
I work with software products that need more than “some help pages”. When a product grows, documentation often becomes scattered across tickets, repositories, internal notes, old pages, UI labels, and people’s heads.
My work is to bring that knowledge together, shape it into a usable structure, and make it easier for users, developers, and teams to understand what matters.
What I do
Through FreeScribe, I help software startups, scaleups, and product teams improve their documentation as both content and system.
That may mean writing user guides, developer documentation, API-adjacent content, release-related documentation, onboarding material, or embedded product text. It may also mean auditing an existing documentation set, redesigning the information architecture, defining templates, improving terminology, or helping a team choose a more maintainable documentation workflow.
The goal is not to produce more text. The goal is to create documentation that answers real questions, supports real tasks, and can survive future product changes.
How I think about documentation
I see documentation as product infrastructure.
Good documentation helps people understand what a product does, how to use it, and whether they can trust it. It supports onboarding, reduces repeated support questions, improves collaboration inside the team, and makes product knowledge less dependent on individual people.
Bad documentation does the opposite. It creates doubt, hides important information, duplicates effort, and makes the product feel harder than it needs to be.
My approach is practical: documentation should be clear, structured, accurate, findable, and maintainable. It should serve the user, support the product, and fit the way the team actually works.
Who I work with
I work best with software teams that have reached the point where informal documentation is no longer enough.
This often happens when the product has grown, the user base has expanded, the team is preparing for scale, or support and product knowledge are becoming too fragmented. The company may not need a full internal documentation department yet, but it does need someone who can bring structure, clarity, and documentation experience into the process.
I can help teams that are starting documentation from scratch, cleaning up an existing documentation set, moving toward docs-as-code, or trying to make their documentation easier to maintain.
How I work
I start by understanding the product, the users, the current documentation, and the team’s workflow. Before writing, I look at what information exists, where it lives, who needs it, and what users are trying to do.
From there, I identify gaps, remove unnecessary complexity, and propose a structure that makes the content easier to navigate and maintain. I ask questions, verify facts with subject-matter experts, and shape technical information into content that is useful to the intended audience.
My work is structured, but not rigid. I care about systems because they make documentation easier to keep alive after the initial writing is done.
Tools and methods
I am comfortable with modern documentation workflows, especially docs-as-code approaches based on Git, lightweight markup, reviews, and automated publishing.
Depending on the project, I may work with Markdown, AsciiDoc, reStructuredText, Sphinx, Antora, Asciidoctor, GitHub or GitLab workflows, CI/CD-compatible publishing, style guides, terminology, templates, and content models.
The tool is never the point by itself. A good documentation setup should match the team’s skills, the product’s complexity, and the maintenance reality behind the scenes.
Experience and credibility
I have worked in technical writing and software documentation since 2007. My experience includes user documentation, developer-facing content, content restructuring, Git-based workflows, open source documentation, documentation reviews, and collaboration with developers, product owners, testers, support teams, and other technical writers.
I bring both writing skill and systems thinking to documentation work. That means I do not only ask, “How should this sentence sound?” I also ask, “Where should this information live, who needs it, how will they find it, and how will the team keep it accurate later?”
Why FreeScribe
FreeScribe is my independent technical writing practice.
The name reflects how I prefer to work: independently, clearly, and with respect for both the product and the people who use it. I believe documentation should make complex things easier to approach without flattening their complexity or pretending they are simpler than they are.
My work sits between writing, structure, and technical understanding. I help software teams turn knowledge into documentation that can be read, trusted, and maintained.
Need help with your documentation?
If your documentation is scattered, outdated, hard to maintain, or simply not supporting your product well enough, a documentation audit is a good place to start.
Tell me what you are trying to fix, and I will help you find the next useful step.