Public relations

The $20,000 tool a comms team now builds for itself

Social listening platforms charged agencies around $20,000 a year. Sam Polstein now builds client dashboards himself with virtually no coding experience.

Comms agencies are starting to build the tools they used to buy. Sam Polstein, who leads communications and content for deep tech startups at HAUS, builds client dashboards, competitor trackers and answer-engine analytics himself, with what he calls virtually no coding experience. The incumbent category he is displacing charged around $20,000 a year for access.

That is not a story about cheaper software. It is a story about who the buyer is now.

What are comms teams building instead of buying?

Narrow, client-specific reporting. Polstein describes the output as analytics and dashboards built for one account at a time.

"Helpful analytics in terms of geo and answer engine optimization, and building dashboards for clients to keep track of their competitors — this kind of reporting that can be really, really helpful, that used to be either very expensive and a huge part of agency overhead, or didn't exist."

Note the second half of that sentence. Some of what he builds replaces a line item. The rest had no vendor at all, which means part of this demand was never visible in anyone's market sizing.

He calls it one of the exciting things about working in comms, and cites a peer's framing for the role change.

"Somebody I know who works at a VC but does communications there recently was like: I've become a product manager. And I think that's totally true."

What did this capability cost before?

Around $20,000 a year, from a category of social listening platforms every agency was buying when Polstein started out.

"At the start of my career ... the big powerful tools of the day, the Crimson Hexagons of the world — essentially a big, powerful social listening tool that every agency was kind of hyping up, and they were charging 20K a year for access. And it's just nuts to now have — you can build a custom solution with me having virtually no coding experience."

Two things in that comparison matter for anyone selling into this market. The price point is one. The other is that the replacement is not a cheaper competitor — it is an afternoon of work by the person who would have been your user.

Where does the building stop?

At the boundary of simple, custom and internal. Polstein is precise about not overclaiming what he is doing.

"It's more about making a pretty simple solution, like building a dashboard. Don't need to be necessarily an advanced software engineer to figure that kind of thing out — but to make it custom and bespoke to your client, and put exactly where you like the information hierarchy, and to do those things with a simple plain English prompt is incredibly powerful."

Read that as a scope statement rather than modesty. He is not rebuilding a data pipeline or a media database. He is rebuilding the presentation layer — the part vendors have historically charged for and controlled, and the part a non-engineer can now specify in plain English with Claude Code.

What does this look like from the client's side?

The same shift, one step further down the chain. Galina Fendikevich, host of Artificial Reality, the AI buyer-evidence podcast, described a strategist at an agency she worked with building her a personalised reporting dashboard. The question stopped being which fields the software offered and became what she actually needed to see.

So the custom build does not stop at the agency. The agency's client gets a bespoke view too, and their expectation resets accordingly.

What should a builder take from this?

My read, drawn from what Polstein describes rather than from anything he prescribes:

Feature breadth is a weak moat when the buyer can specify their own view. Both Polstein and Fendikevich describe the same move — away from the fields a product offers, toward the information hierarchy the user wants. A long feature list is not an answer to that.
Your competitor may be a comms lead with a prompt. Not a startup, not an incumbent. Someone with domain knowledge, no engineering background, and a tolerance for building something narrow that only they need.
The reporting layer is the exposed surface. Data acquisition — who covered what, when, where — is still hard, and Polstein has not replaced that. Dashboards on top of it are what he now makes himself.

So what

If you sell tooling into agencies, the honest test is narrow: what does your product do that a competent non-engineer cannot assemble for themselves in an afternoon with a plain English prompt? Data nobody else holds passes that test. A dashboard does not.

And if the answer is uncomfortable, the more useful question is the one Polstein's own workflow implies: what would it take to sell that person the inputs instead of the interface?