Building cutePR from a real PR constraint

PR work is not only a list of contacts.

It is contacts, media outlets, markets, languages, topics, campaigns, product sends, follow-ups, coverage, proofs, EMV, reports, and the uncomfortable amount of memory that lives in someone's head because the tools around them do not connect it cleanly.

A journalist is not just a row. A product send is not just a note. A piece of coverage is not just a URL. A report is not just the last spreadsheet someone exported under pressure.

The work is relational.

The usual tool split becomes painful there.

Excel can hold data, but it does not really understand the relationships. Outlook can send, but it is not a campaign memory. Enterprise suites can do a lot, but they often arrive with sales-led pricing, contract weight, and more platform than a small team can justify. Narrow reporting tools can make the final deck easier, but they do not start where the operator's day starts.

The operator still has to stitch everything together.

The product opportunity lives in that stitching.

cutePR started as a practical answer to that gap.

Not as a public SaaS claim. Not as a Launchmetrics clone. Not as a generic CRM with PR labels added on top.

The first version had to answer a sharper question: what would a calm PR cockpit look like if it started from the daily operator instead of the enterprise procurement page?

That means the product starts with the unglamorous things.

Import the messy CRM export. Keep accents and semicolon CSVs intact. Let the operator review rows before anything enters the database. Preserve duplicate hints instead of deleting evidence. Separate contacts, media outlets, markets, languages, and topics relationally. Keep campaign audiences clean. Prepare Outlook exports without sending email automatically. Record product seeding as a manual ledger. Link coverage to campaigns and products. Make EMV visible and justified. Freeze report snapshots so numbers do not move after the report is generated.

The list is not flashy. That restraint is exactly why the product is interesting.

The first value is not automation. It is making the work hold together.

The current version is used first as an internal tool for that PR manager.

That keeps the product honest. The first user is not an abstract persona. The first workflow is not invented for a landing page. The product can be judged against a real day of PR work: import, clean, select, prepare, track, score, report.

But I did not build it as a disposable one-off script either.

It already has a landing page direction, a pricing study, a provider benchmark, a brand system around cutePR rather than the repository placeholder tinyPR, and a roadmap that separates the current build from later claims.

That tension is useful.

cutePR is a prototype with one real operator at the center, but it is built around a broader thesis: this need is probably not unique.

Small in-house PR teams, boutique agencies, lifestyle brands, product-led companies, and founder-led teams can all hit the same wall. They are too mature for scattered spreadsheets, but not ready for heavy enterprise PR software.

The product lives in that gap.

A lot of software gets worse when it tries to look more impressive than the work requires.

cutePR has the opposite design pressure.

It should be dense, calm, table-first, and easy to scan. The default layout is not a card wall or a marketing dashboard. It is closer to:

Left nav. Main list or workspace. Right inspector drawer.

That sounds simple, but it changes the product's posture.

Contacts stay visible as an operating table. A selected contact opens a drawer instead of a separate profile theatre. Campaigns become working folders, not landing pages. Coverage rows stay close to evidence, products, markets, and EMV. Reports are generated from frozen snapshots instead of being improvised as a final cleanup pass.

The brand can be warm. The app can be pleasant. The bee mark can make the product more memorable.

But the interface still has to respect repeated work.

Cute, here, means well-tended. It does not mean decorative.

The obvious temptation with a product like this is to overstate the AI layer.

Let the agent clean the database. Let the agent find contacts. Let the agent score coverage. Let the agent write reports. Let the agent do everything.

That would be the wrong shape.

PR work has too much relationship risk for invisible automation to be the default. A wrong contact, invented email, bad merge, inflated EMV, or careless report sentence can create real damage.

So cutePR uses a review-first AI boundary.

Codex can propose. The operator validates. The app persists only after accept, edit, or reject.

That rule appears throughout the architecture. Codex jobs run in scoped workspaces. They receive limited exports. They produce structured artifacts. The app validates outputs with schemas. The review UI shows what changed. Business tables are updated only through app-owned services.

That makes AI useful without letting it become the hidden owner of the system.

The most interesting jobs are exactly the painful ones: contact enrichment, source-backed prospecting, coverage analysis, EMV explanation, report narrative drafting.

AI helps most when it reduces the dull research and synthesis load while leaving the operator in control of the relationship.

cutePR is not ready to claim enterprise parity.

It does not own a verified global media database. It does not bundle licensed monitoring. It does not send email in V0. It does not scrape social platforms. It does not automate shipping or creator fulfillment. It does not pretend that provider data becomes app-owned just because an API returned it.

Those constraints are not weaknesses to hide. They are part of the product's honesty.

The strategy is modular. Provider data can come later through explicit integrations, contracts, source attribution, cache rules, review states, and license-aware storage. The product should own the operating memory: the relationships, decisions, notes, campaigns, product sends, evidence, EMV versions, report snapshots, and accepted AI artifacts.

The value compounds there: not by pretending to be every provider, but by becoming the calm layer where the work becomes usable.

cutePR is a good example of the kind of product work I like most.

A real constraint appears. The market is checked before building. The existing options explain the gap. The first user is concrete. The architecture follows the workflow. The brand has a point of view without weakening the tool. The AI layer is useful because it is bounded.

It also shows why small internal tools can matter.

Sometimes a personal prototype is not small because the problem is small. It is small because the first user is close enough that the product can be built with unusual precision.

The question is what happens after that.

If the prototype keeps working for the first operator, the product gets better evidence. If the same pain appears elsewhere, the landing page has a reason to exist. If the workflow keeps expanding without losing its calm center, cutePR can become something larger than a helpful internal app.

That is the path I want to follow.

Not a giant PR suite from day one. Not another AI wrapper. Not a spreadsheet template with a nicer logo.

A PR operating system, grown from the work itself.