Senior Technical Writer · Documentation Lead
I've spent more than ten years writing API references, integration guides, product guides and release notes. I test what I document before I publish it, and I work closely with the engineers and product people who know the details.
{
"role": "Senior Technical Writer",
"based_in": "Buenos Aires, AR",
"timezone": "UTC-03:00", // North America overlap
"focus": [
"API & developer docs",
"OpenAPI / Swagger",
"AI-assisted doc workflows"
],
"languages": {
"es": "native",
"en": "full professional",
"ja": "basic"
},
"open_to": ["employee", "contractor"],
"work_mode": ["remote", "hybrid"] // hybrid in Buenos Aires
}
I didn't start out in tech. I studied Economics, got interested in film, and ended up with a degree in Sworn Translation from Universidad del Salvador. Translation taught me to read for exact meaning, and that turned out to be a big part of this job.
Before moving fully into documentation, I worked as a localization Project Manager, coordinating translators, quality control, client communication and delivery dates. That experience shapes how I plan documentation work across teams today, from tracking dependencies to spotting gaps before a release.
My interest in software documentation started while I was studying Android development. I wrote guides for myself as I went, other students started using them, and then the instructors adopted them too. Later, my first technical writing work was documenting quantitative financial models for Wells Fargo. I had to learn the math from scratch so I could work with the analysts, and every document went through internal model validation.
Since then I've documented marketing automation, travel, logistics and restaurant technology products. I've often been the only writer, or the most senior one, on the team. Outside work I wrote a Flutter reference in Spanish, answered questions on Stack Overflow, and co-organize a small technical-writing group in Buenos Aires with another writer.
Technical writing with a QA mindset, a functional-analysis perspective and a project manager's way of planning the work.
I find out how a product is supposed to work, test how it actually behaves, and turn the difference into documentation people can rely on.
I run workflows and API calls, take part in QA and UAT, and report defects in Jira while the feature is still in development.
With product owners and engineers, I pin down what a feature should do, how data moves between systems and who owns each step. Diagrams expose the missing pieces early.
API references connected to the full task: prerequisites, request order and examples. I check every call against the OpenAPI spec, and when the spec is wrong, I fix it in the repository.
I interview component owners, adapt to how each one explains things, and turn what they know into architecture docs the whole team can use.
Product guides, help-center articles and tailored docs for customers and prospects, written with Support and Customer Experience so they match what the product does.
Docs-as-code, release notes written from sprint demos, and Python and AI-assisted workflows for recurring tasks, with human review before anything is published.
Most of my professional documentation lives in access-restricted company portals, so I can't link to it. Below is an independent writing sample, followed by two projects described without confidential material.
Need more samples? I can share additional ones privately or walk you through them in an interview. Get in touch →
A short integration guide for a fictional restaurant ordering API: prerequisites, a request, an expected response and recovery steps.
Demonstration only. This API is invented and example.com is a reserved placeholder host, so these requests can't run against a real service.
Create a sandbox order and retrieve its status. Sandbox orders don't reach a restaurant or trigger a payment.
orders:write and orders:read permissions.export BASE_URL='https://sandbox.example.com/v1'
export API_TOKEN='YOUR_SANDBOX_TOKEN'
export LOCATION_ID='YOUR_LOCATION_ID'
export ITEM_ID='YOUR_MENU_ITEM_ID'
export ORDER_KEY='demo-order-001'Use a new ORDER_KEY for each new order. Reuse the same key and request body only when retrying an order whose response was lost.
curl --include --request POST "$BASE_URL/orders" \
--header "Authorization: Bearer $API_TOKEN" \
--header 'Content-Type: application/json' \
--header "Idempotency-Key: $ORDER_KEY" \
--data @- <<EOF
{
"location_id": "$LOCATION_ID",
"items": [{ "item_id": "$ITEM_ID", "quantity": 1 }],
"fulfillment_type": "pickup"
}
EOFExpected response: 201 Created. Save the returned id for the next request. A created order doesn't yet mean a restaurant has accepted it.
{
"id": "ord_demo_001",
"status": "received",
"location_id": "loc_demo_001",
"fulfillment_type": "pickup"
}export ORDER_ID='ord_demo_001' # Replace with the returned id
curl --include "$BASE_URL/orders/$ORDER_ID" \
--header "Authorization: Bearer $API_TOKEN"Expected response: 200 OK, with the same order ID and its current status.
Prerequisites make dependencies explicit. The request and response give a success condition the reader can check. Idempotency and error guidance cover what a developer needs when the happy path fails.
Developer documentation for several products, published in an API portal I administered in Document360.
Internal engineering documentation spread across Confluence and GitHub, moving to a Backstage developer portal.
Degree in Sworn Translation from Universidad del Salvador (4 years). Translation trained me to read for exact meaning, which is most of what good technical writing asks for.
Email me to talk about a role or to request additional writing samples.