cutePR

Context

cutePR started with a practical constraint, not a SaaS idea.

A PR manager close to me was working in an environment where the daily work was real, but the tooling budget was not shaped for enterprise suites like Launchmetrics, Cision, Meltwater, or the heavier influencer and monitoring platforms.

The first move was obvious: benchmark the market and find the affordable product that already solved the problem.

The obvious product was not there.

There were enterprise suites, reporting tools, influencer platforms, media databases, monitoring products, and templates. But the useful middle was weak: a calm operating cockpit for contacts, media outlets, campaigns, products, seeding, coverage, EMV, and reports.

cutePR began there.

Product Shape

cutePR is a PR operating system before it is a public product.

It is designed for one real operator first: someone who needs to import messy contact data, clean it, prepare campaigns, track product sends, record coverage, justify EMV, and produce reports without losing the relationship memory in disconnected files.

The product is deliberately table-first.

The default shape is simple:

• left navigation
• dense main table or workspace
• right inspector drawer
• compact filters and actions
• no decorative dashboard theatre

The brand direction is softer than the implementation name tinyPR, but the product stays serious. cutePR means cute utility: warm, precise, memorable, and pleasant to return to, not childish or mascot-led.

What Is Already Real

The current build is a working monorepo with a real database model and usable product surface.

It already covers:

• closed internal auth
• contacts for journalists, influencers, and hybrid PR profiles
• Excel and CSV import with review before persistence
• media outlets, markets, languages, topics, and relationship notes
• duplicate detection and human-approved merge flows
• campaign workspaces with audience, products, assets, send prep, review, and timeline
• product and product-seeding ledgers
• coverage capture with evidence and manual EMV
• report snapshots with web, Excel, and PDF output
• Codex jobs for enrichment, prospecting, coverage analysis, and report narrative drafts

The important rule: AI does not own the database.

Codex proposes. The operator validates. The app persists only after human accept, edit, or reject.

Architecture

The stack is intentionally boring where the product needs trust.

cutePR uses Bun workspaces, a Next.js App Router web app, PostgreSQL, Prisma, Better Auth, SheetJS for import/export workflows, Playwright for PDF rendering, and a controlled Codex runtime boundary.

The architecture separates the app-owned business memory from temporary AI workspaces. Codex jobs receive scoped exports and strict output schemas. They never receive database credentials, never send emails, never delete contacts, and never write directly to the primary tables.

That boundary is central.

PR work is relationship work. The app can accelerate research, cleanup, analysis, and writing, but it should not pretend that judgment has disappeared.

Tradeoffs

cutePR is not trying to replace every PR suite at once.

The current product makes a few deliberate calls:

• Outlook remains manual in V0
• no public signup
• no automatic email sending
• no automatic social scraping
• no creator marketplace
• no claim of owning licensed media databases
• provider integrations stay modular and license-aware
• EMV stays transparent and versioned, not black-box scoring magic

That restraint keeps the product honest.

The first value is not automation spectacle. It is a reliable PR memory that connects contacts, campaigns, products, coverage, reports, and reviewed AI work in one place.

Direction

cutePR began as an internal tool for a real workflow.

It is already more than a spreadsheet replacement, and not yet a public SaaS promise. That middle state is productive.

It lets the product stay close to one operator's daily reality while still testing a broader thesis: small PR teams, boutique agencies, and product-led brands need something calmer and more accessible than enterprise suites, but stronger than Excel.

The next work is to keep hardening the operating core, improve the public landing, refine onboarding, and make the first real user workflow feel effortless enough that the product can move beyond its initial private context.