In brief
You will have technical documentation that your engineers or operators can approve, your support team can point to, and your users can follow without filling the gaps themselves.
I will pull the half-finished material out of tickets, wikis, and PDFs, confirm the missing steps with the people who know the system, then write and structure the docs so users follow them without guesswork. If you want to move ahead, I will send a short intake list and book the first interviews.
I start by getting the current truth onto the table: what exists today, what is outdated, and what people are relying on in their heads. I interview the right subject matter experts, build an outline you can sign off on, then draft, review, and revise until the docs match how the product or process actually works.
A bit about me
I am Martín Rojas, a technical writer. I do technical documentation when a release or process change forces the question: “what do people need to do, in what order, without mistakes”. Most of my weeks are spent turning scattered notes into a set of pages that reads one way, uses one vocabulary, and holds up in review.
I get hired when a client does not want tidy-looking docs that hide missing steps. I ask for a walkthrough, I write down what actually happens, and I flag every “someone does X” that has no owner. You will see the outline early, and you will always know what is blocked and what I need to unblock it.
Recent work
Here are three recent technical documentation jobs like the one you are trying to get finished and approved.
Portfolio
Installation guide rewrite. Consolidated an outdated PDF and ticket notes into a single installation guide with clear prerequisites, verified steps, and rollback instructions. Support tickets dropped because the guide stopped skipping the “obvious” parts.
SOP set for shift work. Captured a day-to-day operating process from two shift leads and turned it into a set of SOPs with decision points, safety checks, and a consistent format. New starters could run the routine without shadowing.
API reference cleanup. Restructured API documentation around real tasks, then corrected request and response examples by testing them against the current build. Engineers stopped answering the same “how do I” questions in chat.
“He found the missing steps fast and the docs matched the real workflow.”
Engineering lead, a product team shipping monthly
How this runs
I keep technical documentation moving by making review easy and specific. You will see the outline early, you will review in small chunks, and I will chase the missing details so nobody has to guess later.
1. Intake and outline Days 1-3 I collect what you already have, including tickets, wiki pages, PDFs, diagrams, and example commands. I interview the key SMEs for the first pass. You will get a draft outline and navigation plan, and you will confirm what is in scope before I draft pages. 2. Walkthrough capture Week 1 I sit with the person who actually runs the workflow or builds the system and capture the steps as they do them. I ask for edge cases, failure modes, and “what people always forget”. You will see a list of open questions where the docs cannot safely assume. 3. Draft and review Weeks 2-3 I draft the pages in the agreed structure and send them for technical review in short sections. Review comments stay tied to a specific step, screen, or API call so engineers can respond quickly. I revise until the pages describe the same reality your SMEs described. 4. Handover and upkeep Week 4 I deliver the final doc set in your chosen tool and format, with links that match the navigation map. I run a short handover so someone on your side can maintain the docs. You will also get a short list of follow-up items that will matter in the next release.
Doc outline and map
A signed-off outline plus a navigation map that shows where each page lives, what links to what, and what content is shared across pages.
REVIEWED DOC SET
The finished set of pages or documents, revised through technical review until the content matches how the product or process works.
PROCEDURE STEPS AND CHECKS
Step-by-step instructions captured from a real walkthrough, including prerequisites, decision points, and the checks that prevent common mistakes.
Style guide and templates
A short style guide and usable templates for headings, notes, warnings, code blocks, and tables, so new pages match the set you approved.
RELEASE NOTES OR CHANGELOG
A set of release notes or a changelog entry format you can reuse, written so support and users can see what changed and what to watch for.
OPEN QUESTIONS LOG
A tracked list of questions and assumptions that came up during drafting, with answers where confirmed and owners noted where confirmation is still needed.
Pricing
Pick the tier that matches how much needs sorting before anyone can review. Each option covers the same four-week flow.
Priced items
Get started
If the scope and timing here match what you need, you can book the work and I will start the intake the same day.
1. Sign the proposal and I will send the booking invoice for 25%. 2. Share the existing docs and name the SMEs for interviews and walkthroughs. 3. Book the first two SME sessions and I will deliver the outline in days.
Signature
Fee summary
Payment
To book time, I invoice 25% when you sign this proposal. I invoice the remaining 75% when I hand over the finished work. Each invoice is payable within 14 days of its date.
What I need from you. Before I start drafting, I need access to the current docs and source material, plus the right SMEs for walkthroughs and reviews. If access or contacts slip, the timeline moves with it.
SME time. I keep SME time tight by coming in with an outline and specific questions. Plan on one walkthrough session per workflow, plus two short review windows where SMEs confirm steps and terminology.
Reviews and sign off. I share drafts in a format you can comment on, with an open questions log beside it. I fold feedback into the next draft, and I treat a written “approved” as sign-off for handover.
Changes to scope
If new workflows, additional doc sets, or major product changes appear mid-stream, I will list what changed and what it means for hours and dates. I only continue once you approve the update.
Existing docs and reuse. I can work from what you already have, including rough notes, tickets, and older PDFs. If I find missing steps or contradictions, I flag them as open questions instead of guessing.
Ownership. Once the final invoice is paid, you own the finished technical documentation I produced for this project. I keep my working files and notes so I can support updates if you ask for them.
