Overview
You ship technical documentation that routes users to the right path the first time, cuts repeat questions to support, and stops engineers being pulled into the same explanation on loop.
Most teams reach out when a new integration or process is about to ship and support is about to feel it. You’ll end up with docs your users can follow and your engineers can stand behind, because every page is traced back to the product, the spec, and the real workflow. Next, I’ll confirm scope, sources, and review timing so drafting can move without guesswork.
I start by pulling the truth from the places it already lives: SMEs, Jira, PRs, and the OpenAPI spec. I map the product surface into an outline, then draft in small, reviewable chunks. I keep a running list of assumptions and open questions so nothing gets quietly invented and published.
About me
I’m Alicia Tan, a technical writer who focuses on technical documentation for SaaS products and operations teams. I got into this work the same way most teams discover they need it: launches got faster, integrations got wider, and “someone will explain it” became a support queue. I write so the product is usable without a meeting.
Clients pick me when they need accuracy more than wordsmithing. I don’t fill gaps with confident guesses. I confirm terms, sources, and user paths before I lock wording in, and I flag mismatches between the spec, the UI, and the real workflow while there’s still time to fix them.
Selected work
A few recent technical documentation jobs that show how I write from specs, tickets, and real workflows, then publish where your team already works.
Portfolio
OpenAPI-based API reference. Turned an OpenAPI spec into an API reference that matched real request and response behaviour. Added auth and error guidance so integrators could diagnose issues without waiting on an engineer reply.
App user guide set. Wrote a user guide for a web and mobile app by walking the product with a PM and support lead. Cleaned up terminology and step order so the guide matched what users see on screen.
Ops SOPs and work instructions. Interviewed SMEs to capture an end-to-end workflow, then wrote SOPs for new hires. Put checks and stop-points into the steps so the procedure prevents the common mistakes, not just describes the happy path.
“The docs matched the product, and support stopped fielding the same questions.”
Product manager, a growing SaaS team
Documentation outline
A page-by-page outline that mirrors the product surface and user tasks. It shows what each page answers, what it links to, and what sources it will be based on.
DRAFT DOCUMENTATION SET
A complete first draft in your chosen home (Confluence, Git, or a help centre). It is written in plain language, with steps and examples a reader can follow.
REVIEWED FINAL DOCUMENTATION SET
The finished technical documentation after the agreed review loop. Edits are applied with source notes, and every changed user path is checked back against the product or workflow.
Terminology and style sheet
A short reference for names, capitalisation, button labels, and preferred phrasing. It keeps future pages consistent, even when different people contribute.
PUBLISH-READY STRUCTURE
Navigation, page titles, and linking that match how users search and how your support team answers tickets. This includes a clean table of contents and cross-links.
ASSUMPTIONS AND OPEN QUESTIONS LOG
A tracked list of items that need confirmation, plus what I used as the source of truth for each decision. It prevents “everyone thought someone else confirmed it.”
What it costs
Pick the tier that matches how much surface area you need documented right now. If you are not sure, the middle tier is usually the right starting point.
Priced items
Getting started
If you want me to hold time for this, the next step is to lock scope, sources, and the first review deadline.
1. Sign this proposal to book the work. 2. Pay the 40% deposit invoice within 14 days. 3. Introduce me to the SMEs and share access to the sources so drafting can begin.
Signature
Fee summary
Can you work from our Jira tickets, PRs, and OpenAPI spec?
Yes. I use Jira and PRs to understand what changed and why, and I use the OpenAPI spec for exact shapes and behaviour. I still confirm any user-facing flow with a quick SME check, because tickets rarely show the full path.
HOW DO YOU HANDLE REVIEWS WITH BUSY ENGINEERS WHO REPLY LATE?
I keep reviews small and time-boxed, and I tell you what I need from whom before drafting starts. If a reviewer is late, I keep moving on sections that are already confirmed and park anything that depends on their answer.
Will you match our existing style, or do we need a new one?
I’ll match what you already have, as long as it is consistent enough to follow. If the current docs fight themselves, I’ll propose a short style sheet and terminology list so new pages stop drifting while the product keeps shipping.
WHERE WILL THE DOCS LIVE: CONFLUENCE, GIT, OR A HELP CENTRE?
Any of the three works. I’ll write directly in Confluence, in Markdown in Git, or inside your help centre editor. Before I start, I’ll confirm how you want changes reviewed and approved in that system so nothing gets lost in comments.
Payment
To book the work, I invoice 40% when you sign this proposal. I invoice the remaining 60% when I hand over the finished work. Each invoice is payable within 14 days.
Change in scope. If the docs set grows or the source material changes mid-stream, I will list the change in the assumptions and open questions log and send a written price and schedule update before I draft new sections.
Your inputs. Before I start drafting, I will ask for access to the agreed sources and one point of contact for reviews. If access or answers are blocked, I will park affected sections and continue with confirmed content.
Reviews and sign-off. I will send review batches with specific questions and a clear due date. If reviewers reply late, I will keep moving on confirmed sections. I can only finalise pages that receive written approval.
Source of truth
I write what I can trace to the product and the real workflow. If Jira tickets, PRs, and the OpenAPI spec disagree, I will flag the mismatch and wait for your confirmation before publishing that section.
Publishing access. You will provide the destination and access for publishing, whether that is Confluence, Git, or a help centre editor. I will confirm how you want changes approved in that system so edits do not get lost in comments.
Ownership. Once the final 60% is paid, you own the final technical documentation I delivered for this project. I keep my working files and notes so I can support follow-on updates, but I do not resell your content.
