I build content pipelines.
Before I ever ran a B2B blog with a $50k/year budget, I spent years on the other side of the relationship as a freelance writer. Filling stories for different types of digital publications, learning how to find an angle fast, interviewing people without wasting their time, and shipping clean copy on deadline.
When I started at Rive, I realized pretty quickly that the blog couldn’t run on “we should write about this sometime.” It needed a process. The product was moving fast, the subject matter was technical, and the best stories lived inside people who weren’t traditionally writers.
So I built a system I could run largely on my own.
Project example: Rive blog
How the pipeline worked
1) Finding stories (and deciding what was worth writing)
Some posts were obvious, like launches. Others came from quieter signals, such as recurring community questions, support patterns, internal debates, or a customer story that revealed a lesser-known use case.
2) Recruiting writers who weren’t “just writers”
A lot of the best pieces needed an expert (engineers, creative technologists, community builders) who knew the tool intimately.
Sometimes I found them inside our ecosystem:
Ambassadors whose posts were already thoughtful and clear
Community members who explained things well without being performative
And sometimes I went looking elsewhere:
Blogs, talks, GitHub write-ups, niche newsletters
The corners of the internet where someone is quickly explaining hard things plainly
I was always searching for that perfect balance of technical depth and a down-to-earth voice.
3) Drafting paths (depending on the story)
I didn’t force every post through the same workflow. Different stories needed different paths.
I wrote the draft myself (when speed/voice mattered)
I ghostwrote after interviewing an expert (when the expertise was the story)
I co-wrote with an internal SME (when we needed their POV plus structure)
A freelancer drafted and I edited (when we wanted scale without dropping the bar)
4) Editing + review (accuracy first, then polish)
The most important part of writing for a technical product is credibility. So I did my best to run reviews in a way that didn’t spiral by locking the technical claim early, keeping one place were edits live, and publishing when it’s solid, not perfect.
5) Packaging with Creative (so the post felt like a real asset)
Text wasn’t the full deliverable. I worked closely with our Creative team to build graphics for each post, often calling the exact pullquotes and pointing to sections that needed a visual.
6) Handing off for distribution (so it actually went out)
Once a post was ready, I handed it off to our Head of Community as a kit she could post from week after week.
7) The unglamorous bits (the reason the machine kept running)
I also handled the operational layer, such as timelines, expectations, and paying freelancers, so the pipeline kept moving even when launches got chaotic. That’s what determines whether content happens consistently, or only when someone has spare time.
