Why I write the content I write
I was a developer before I was a writer.
And like most developers, I spent a lot of time searching for answers that didn't exist the way I needed them to. Not because the information wasn't out there, but because most technical content explains what a tool does without showing how to use it for a real problem.
I'd find a tutorial, follow it to the end, and still not know how to apply it to what I was actually building. I'd close ten tabs. Stay stuck. Eventually figure it out myself.
That frustration is why I started writing technical content. Not because I saw a market opportunity. Because I wanted the tutorials I kept not finding to actually exist.
I still use my own articles as reference when I get stuck on a problem I've already solved and written about. That's the quality bar I hold every piece of content to: would I have found this useful when I needed it?
What I do and how I do it
I write implementation-first tutorials for developer tool companies—APIs, auth tools, AI tooling, BaaS, and frontend infrastructure.
My work helps developer tool companies show up in Google, AI answers, and developer communities where developers are choosing which tool to use.
Find the real question first
I research what developers are actually asking on Reddit and community threads, not what your product team thinks they're asking.
I build before I write
I create a working project using your tool around that specific problem. This is how I find the edge cases developers need to see to trust a tool.
I write the implementation
I document what I built and the problem it solves. The result reads like it was written by a developer who solved this problem, not a writer who read the docs.
I publish where developers search
The tutorial goes where developers and AI tools look for answers: HackerNoon, FreeCodeCamp, DEV, your company blog, or a combination.
A few things worth knowing
"I like your conversational style."
Quincy Larson
Founder, FreeCodeCamp
I contribute to FreeCodeCamp and JS in Plain English (accepted to both on my first application.)
A FreeCodeCamp article I wrote ranks #1 on Google for its target keyword and appears in AI search results.
Ghostwritten tutorials I've built for developer tool clients appear in AI overviews and rank for the searches their developers are running.
I've worked directly with developer tool companies including Permify and Zuplo.
A tutorial I wrote covers a use case an official docs set didn't address. Developers in the relevant subreddit are actively searching for exactly that solution.
Visual Proof: Google Ranking #1
"How to Build a custom PDF parser"
freecodecamp.org/news/...
Verified search visibility for high-intent developer queries.
What I believe about developer content
Implementation beats explanation
Developers don't need to be told what a tool does. They need to see it working in a situation they recognize. Real workflows earn trust faster than feature overviews.
The platform matters as much as the content
A company blog is the last place developers trust. Content on FreeCodeCamp, DEV.to, and Reddit reaches developers where they already are — and where AI tools index for recommendations.
Reddit tells the truth
What developers say in community threads when no one is watching is more honest than any survey. It's where the real content brief lives. Most companies never read it.
If you're thinking about working together
I work with DevRel leads, developer marketing managers, and content managers at developer-first SaaS companies. Usually Series A to C, with a small content team trying to do a lot with limited capacity.
The companies I work best with have a good product and a specific problem: developers aren't finding them during evaluation, aren't getting through onboarding, or aren't trusting their content enough to try.
If that's where you are, the fit call is the right first step. It's 30 minutes. No pitch; just a conversation about where your tool is missing from the developer's decision process.