Building an AI PR Practioner: What I Learned By Building It From Scratch

The article is proudly em-dashed by Claude, with images created by Nano Banana 2

One of the universal truths in growth and communications is that sooner or later, someone pushes back on cost. And the biggest pushback is almost always around PR.

I’ve heard every version of it over the years. Why does this cost so much? Do we really need to pay someone for this? Why can’t anyone guarantee coverage? Sometimes founders say it politely in meetings. Sometimes they wait until the invoice arrives.

And honestly? The frustration makes sense. PR sits in this awkward category where it’s essential for brand credibility and media visibility, but it’s also one of the hardest things to put a number on. Coverage takes time, journalists move at their own pace, and retainers are a tough sell for startups and scaleups focused on revenue and growth. Startups are told they need PR, but the way it’s traditionally delivered feels expensive, slow and opaque. AVEs - Ad Value Equivalents - are the moribund reptile of metrics and the industry standard. Media monitoring adds another service and cost layer.

That was my problem statement. I wanted to know whether it was possible to build an engine that was faster, more holistic, less polished but still effective compared with traditional means — and not make it a disaster. I wanted a tool that would:

• Replace the most time-consuming parts of the PR process — the journalist research, the angle development, the outreach drafting.
• Cut the cost of a $10,000-a-month retainer down to something a startup could actually stomach.
• Let me apply twenty years of journalism and communications experience in a way that scaled beyond my own hours.
• Not be embarrassing.

It’s built. And after a lot of mistakes, it works. My business partner Meredith - a recovering PR person - is amazed by it (she is also editing this piece, hi! :) Here’s what I observed in the process.

Your domain knowledge is king. Without it, you’re making toys.

The first thing I learned quickly: vibe coding works best when you have genuine domain expertise in the space you’re building for. It might be all the rage as a hobby, but I’m not building an agent to find the coolest new cafes — what’s inside my head actually matters.

My background helped a lot. I’ve spent half a career working across communications as a writer, journalist, editor and PR agency owner. I've also been a founder and I've worked extensively with founders.

I’ve sat on all sides of the media equation — pitching stories and receiving pitches, needing the publicity for my business and advising founders not to pay too much for publicity. That domain knowledge becomes your compass when you’re building. Without it, you’re just making toys.

The hard truth for builders out there, is that you need to know what good and bad actually looks like to solve the problem, and that means knowing deeply:

• Where the PR process breaks down and where agencies add real value versus “that’s how it’s always been done.”
• What frustrates clients — the opacity, the slow timelines, the retainer model that charges regardless of output
• How journalists actually think — what they ignore, what angles get traction, how quickly weak messaging falls apart when it hits an editor’s desk.
• Why the process takes so long sometimes, and where you can cut the fat

Ignore the noise and JFDI

So how did we go from "I know how to solve this" to "creating a product"? It can be difficult to get started, because there is genuinely so much noise right now about AI that makes building sound much easier than it is. LinkedIn is full of elaborate prompt frameworks and “AI strategy” posts from people who aren’t actually building anything. So I totally ignored them and did it from scratch on my own.

V1 was simple — I mapped the PR process from end to end. What does the full workflow actually look like? Where do teams waste the most time? Once you understand that properly, the build becomes practical. My stack was even simpler:

• Used ChatGPT to help scope the problem and develop the first prompts.
• Then used Claude Code to build the system itself.

The first version was, to put it kindly, a bit of a mess - the code wasn't great, but that's because I was building a project, so I had to make sure the process was correct before worrying about anything else.

Build for function first. Form is later

For example, I deliberately forgot about the UI in the first iteration. Only after I’d finished the back-end of the V1 system, did I allow myself think about what it should actually look like. Is this the optimal process? Probably not, but its the process that allowed to focus solely on the problem and not how easy it was to use. That worked for me, it might not work for everyone.

What I did have, from early on, was a long list of things in the industry that were broken. That list became the roadmap. Step by step, fix by fix, it improved:

• Better angle generation — moving from generic pitches to something a journalist might actually open.
• Smarter journalist prioritisation — filtering by relevance rather than blasting a list.
• Cleaner outreach logic — so emails didn’t read like they were written by a committee of robots.

The first working version came together over a weekend — about four hours to get the bones in place, then many more hours of iteration until it started to resemble something actually useful. But the smart thing — after the initial slog, I did it in front of the TV, looking over every five minutes to test something. Smiling and pausing my show to test every finished iteration. Is it perfect? No? Is it effective? Yes? A $10,000-a-month process might now be able to run closer to $3,000. For a founder that doesn’t have time to research media angles or figure out how to target journalists properly, that difference is enormous.

Key takeaways

A few things I’d pass on to a newbie builder, building something they care about:

• JFDI — just start, because the first version will not be the best and that’s fine.
• Domain knowledge will always beat flashy clickbait prompt styles.
• Iteration is the real work, not the first build. No matter how good your prompting is, it’s not going to be that good — so don’t beat yourself up that you aren’t writing 100-line prompts.
• Don’t share too early — too many outside opinions too soon will cause problems, because everyone has an opinion. Build, share, see the iteration point and repeat.

I built this because almost every founder I’ve ever met has complained about the same problem, and I wanted to know if a better answer existed. It turns out one did. It just took a lot more trial, iteration and stubbornness than the AI hype cycle ever admits.

Total Build Cost: Platform + weekend of stubborn iteration + 20 years of domain knowledge