How Can a Technical Writer Show API Docs, Tutorials, and Sample Repositories When Client Work Is Private?
A technical writer should pair authorised public samples with anonymised client cases that explain the audience, documentation problem, exact contribution, review process, and safe evidence without copying private pages.
Documentation often lives behind logins, inside repositories, or on sites that change after handoff. A portfolio cannot be a list of inaccessible URLs; it must tell a hiring manager what kind of artifact existed, what you owned, and which public sample best demonstrates the same skill.
Which technical writing samples belong in the portfolio?
Include your strongest public API references, tutorials, quickstarts, sample repositories, migration guides, release material, and approved case studies, each selected for a distinct skill.
Choose complete samples that a reader can understand without company access. For collaborative docs, state whether you researched, wrote, edited, tested code, designed the information structure, or maintained the content.
A private engagement can be represented by an anonymised case if the agreement allows it. Describe audience, source material, constraints, deliverables, and your role without reproducing proprietary text or internal screenshots.
What is the fast way to build the writing portfolio with IndieShow?
The fast way is to create one IndieShow project card per substantial documentation set or case and group it by whether it is shipped, maintained, in progress, or archived.
Use a tag such as API reference, tutorial, sample app, or docs architecture. The description should make your role and the intended reader clear, while the single destination points to the public docs, repository, published article, or approved case study.
Lead with samples that match the role you want. IndieShow's stable personal URL lets you revise the selection as documentation is updated or removed without changing the link on your résumé.
Build your IndieShow pageClaim your handle, organise the evidence in the editor, then review the $15 one-year and $30 lifetime publishing options in the dashboard.
Should API docs, a tutorial, and its sample repository be separate projects?
Keep them together when they are one documentation experience, and separate them only when each artifact has its own audience, ownership, and maintained destination.
One launch may include a reference, quickstart, and sample app that work as a set. A single project card can explain the system and direct readers to the best starting page.
A reusable sample repository or independent tutorial series can deserve its own card when it demonstrates work beyond the parent documentation and remains useful on its own.
How do you make a private documentation case credible?
Make it credible by defining the audience, starting problem, information or code sources, your decisions, review boundary, and approved outcome without inventing usage statistics.
Explain how you verified examples or coordinated subject-matter review if that was your responsibility. Do not claim technical correctness for areas another team owned without saying how approval worked.
When no public destination exists, an approved case-study page is preferable. If even that is prohibited, omit the client rather than publishing excerpts or recreations that breach trust.
Related IndieShow articles: choosing proof for API projects · presenting confidential client work
How does IndieShow keep a technical writing portfolio maintainable?
IndieShow keeps it maintainable by giving every documentation project a short role-focused summary, status, tag, optional metric, image, and controlled link on one page.
Check samples while signed out, replace moved documentation URLs, and archive material that no longer reflects your current standards. Describe historical work as historical when another team now owns the live page.
Your IndieShow page becomes the answer-first index; detailed docs and repositories remain at their authoritative destinations, where readers can inspect the actual writing and code.
Frequently asked questions
Which technical writing samples belong in the portfolio?
Include your strongest public API references, tutorials, quickstarts, sample repositories, migration guides, release material, and approved case studies, each selected for a distinct skill.
What is the fast way to build the writing portfolio with IndieShow?
The fast way is to create one IndieShow project card per substantial documentation set or case and group it by whether it is shipped, maintained, in progress, or archived.
Should API docs, a tutorial, and its sample repository be separate projects?
Keep them together when they are one documentation experience, and separate them only when each artifact has its own audience, ownership, and maintained destination.
How do you make a private documentation case credible?
Make it credible by defining the audience, starting problem, information or code sources, your decisions, review boundary, and approved outcome without inventing usage statistics.
How does IndieShow keep a technical writing portfolio maintainable?
IndieShow keeps it maintainable by giving every documentation project a short role-focused summary, status, tag, optional metric, image, and controlled link on one page.