The technical writer
engineers enjoy working with.
I write for technical teams that want substance, not content that falls apart the moment an engineer reads it.
Programmer first. Writer second.
Before I wrote a single word for a client, I spent years writing code. Reading documentation at 2am. Cursing at it. Occasionally thanking whoever wrote the one guide that actually showed the edge case that was breaking my build.
That experience doesn't leave you. When I write a tutorial now, I'm the developer reading it. When an example feels hand-wavy, I notice. When the setup instructions skip a step that trips up everyone, I've been that person. The output reflects that.
My engineering background isn't a line on a CV. It's why Centus's devs pushed my guides straight to publish without a revision cycle. It's why LinuxForDevices' audience, a group of people whose hobby is spotting incorrect terminal output, trusted the content enough to cite it in their own Stack Overflow answers.
Six years. 30+ companies. One thing they all needed.
The pattern across every engagement: smart teams, genuinely good products, content that wasn't matching what their audience actually wanted to read.
Developers don't read marketing. They read documentation, implementation guides, and technical posts that respect their intelligence. They'll close a tab the moment something rings false. Writing that works for this audience requires knowing what "technically correct" actually means, not just being able to approximate it.
What I work on
DevTools and B2B SaaS whose buyers are developers or technical decision-makers. The work usually falls into three categories:
- Technical tutorials and implementation guides. Step-by-step walkthroughs where the code runs, the concepts land, and the edge cases are in there because I hit them myself.
- Developer-facing blog content. Long-form technical articles on AI agents, testing infrastructure, localization workflows, vector search, and whatever the engineering community is thinking about this quarter.
- Content strategy and SEO. Building topical authority for technical products. 487 to 203,400 monthly visits for LinuxForDevices. 7,000 to 450,000 for Kiwi Sizing. That kind of thing.
How I work
Small client list, on purpose. When I take on a project, I'm actually inside the product, reading the docs, running the API, understanding what's actually hard about the implementation. That level of attention isn't scalable. I don't pretend it is.
Responsive. Hits deadlines. Will tell you when the brief is wrong rather than quietly write around it. Engineers call my work accurate. Editors call it minimal-revision. Those two things don't usually come together.
Based in India
Working with companies across the US, UK, and EU. Fully async, entirely comfortable with remote-first teams, zero timezone drama.
Our devs called it 'awesome' and just sent it ahead for publishing.
A skilled B2B SaaS writer with the coding chops to boot, closing the gap in a very important writing sphere.
His work usually requires minimal editing and when it does, he is fast and responsive to recommendations.
Ninad is one of the best writers I've worked with to date, especially brilliant with technical writing projects.
Let's work together.
Currently accepting new clients. Technical writing, tutorials, and content strategy for DevTools & SaaS.