posts

The AI product tooling space has split into two camps. Neither is solving the actual problem.
Camp 1: PRD Generators
Tools that take your rough idea and produce a polished Product Requirements Document. Features, user stories, acceptance criteria. Formatted for Confluence. Designed for stakeholders to read and approve.
What they actually do: Bring constraints at human speed—meeting speed, review cycle speed, organizational alignment speed.
PRDs emerged from a world where the bottleneck was building. When development took months, you could afford weeks of requirements gathering. The constraint velocity matched the build velocity.
In the vibecoding era? You can spin up an MVP in a weekend. PRD generators are bringing a knife to a gunfight.
Camp 2: AI Coder Plans
Cursor's plan mode. Claude's implementation outlines. Step-by-step breakdowns of how to build something.
What they actually do: Assume the product decisions are already made. Zero constraints—just execution.
These tools are phenomenal at "implement authentication with JWT tokens." They're useless at "should I even build authentication, or is social login enough for my MVP?"
AI coder plans solve an implementation problem. They don't provide constraints. They don't challenge assumptions. They don't tell you when you're building the wrong thing.
The Problem Nobody's Naming
Here's the failure mode that's killing vibecoded projects:
Build velocity now exceeds constraint velocity.
Before vibecoding, constraints entered projects through:
* Tribal knowledge at your company ("we only ship to US buyers")
* PM traffic-copping ("we can't do that because of X")
* Customer meetings ("actually, we need Y instead")
* MVP methodology (fail fast = learn constraints fast)
All of these operate at human speed. Meeting speed. Calendar speed.
Vibecoding operates at AI speed. You can build in an afternoon what used to take a sprint. But your customers can't give you feedback every afternoon. Your PM can't review every afternoon. Your market research doesn't update every afternoon.
The result: you ship faster than you learn.
The AI makes reasonable assumptions. Those assumptions work in isolation. But they don't agree with each other over time. Your product accumulates coherence debt—decisions that made sense locally but conflict globally.
What's Actually Missing
PRD generators produce constraints at human speed.
AI coder plans produce no constraints at all.
What we need: constraints at AI speed.
Not arbitrary friction. Not "slow down." But the right constraints, surfaced at the right moment—constraints that come from your accumulated context, not generic best practices.
This is why the solution isn't another document format. It's a different architecture entirely.
The Secret Third Thing
PRDs are documents. Plans are instructions. Neither has memory. Neither learns. Neither accumulates.
The secret third thing is a context graph—a persistent structure that captures your product decisions, user learnings, validated assumptions, and rejected paths. Nodes and edges, not paragraphs and bullet points.
When you ask "should I build this feature?", the system doesn't start from zero. It knows:
* Which personas you've validated and what they care about
* Which assumptions you've already tested (and which failed)
* What constraints emerged from past pre-mortems
* What patterns keep appearing across your products
This isn't a document you read. It's a system that remembers—and surfaces relevant constraints exactly when you need them.
Vibeharshing at the Speed of Vibes
We need a word for this: vibeharshing.
Not killing the vibe. Not stopping vibecoding. But bringing product constraints at the speed vibecoding demands. Matching constraint velocity to build velocity.
Code review tools like Greptile and Coderabbit provide constraints on how you build—code quality, security, best practices. Important, but not sufficient.
Vibeharshing provides constraints on what you build—product judgment, user needs, market reality. The stuff that determines whether your beautifully-coded feature matters at all.
The context graph is what makes vibeharshing possible. Without memory, every constraint check starts from zero. With a graph, constraints compound. Your second project benefits from your first. Your tenth feature benefits from your first nine.
The New Stack
Here's what modern product development looks like:
1. Ideation → Your brain, caffeinated, 2am
2. Vibeharshing → Context graph surfaces relevant constraints
3. Planning → AI coder's plan mode
4. Implementation → AI coder's agent mode
5. Learning → Back to the graph—capture what you learned
PRD generators slot into traditional processes between steps 1 and 3. But for vibecoding, that slot doesn't exist. You go from idea to code in minutes.
What you need is constraints that arrive at the speed of thought. Before you tell Cursor "build this," you need to know if "this" is worth building—informed by everything you've already learned.
That's the secret third thing. Not a document. Not a plan. A context graph that harshes your vibe at the speed your vibe requires.

Ready to harsh the vibe? Try Cutline's pre-mortem and stress-test your next idea before you write a line of code.

Not a PRD, Not a Plan, But a Secret Third Thing


Changelog

## Why I Built a Product Cofounder

As you know, I’ve been deep in the trenches building **TextGuardian**—a personal antiscam coach available over SMS. The core concept seems simple at first glance: users forward suspicious texts, and TextGuardian analyzes them to determine if they're scams.

It sounds straightforward. It hasn't been.

I’ve been busy relearning a lesson I’ve encountered many times in my Trust & Safety AI/ML career: people love Safety as a concept but struggle to evaluate and price it as a good. We Security professionals know that while what we offer is relative risk reduction, most buyers want an absolute cure-all. Couple that with some other challenges in the space: going to market with an SMS app, selling primarily to seniors, selling AI to consumers; and I knew I had to uplevel my product and GTM game fast. 

So I turned to the Magic 8-Ball of these times: I asked ChatGPT what to do. In lieu of a product co-founder, I went deep with ChatGPT in many, many conversations, with such prompts as "Act as a skeptical product manager. Review this product idea and identify the top 5 risks that could kill it." and "What are the key assumptions we need to validate before building this feature?"

These prompts got the job done, but they were **fragmented and inconsistent**. Each conversation was isolated. I'd lose context between sessions. The outputs weren't structured in a way that made them actionable. And worse yet, it was optimistic to the point of being naive.

“You’re Absolutely Right!!!” probably boosts morale when you’re in the trenches (I suspect that phrase is in post-training data for the express purpose of keeping developers burning tokens longer) but it’s a rotten tenet for product vision. In the age of vibecoding, velocity has never been greater, but the direction of our vector has maybe never been more aimless.  Where is the Cambrian explosion of production apps we’ve all been vibecoding? I suspect the vast majority of them are getting desk-drawered between the prototype and production stage, partially due to productionalization challenges but probably more due to GTM & product realities.  
I needed special purpose AI that was more systematic, but above all, candid. Something that could:
- Maintain context across multiple product decisions
- Structure outputs in a consistent, actionable format
- Integrate with my workflow (not just a chat interface)
- Learn from previous analyses

## Cutline : An AI Product Manager that Says No

That's when I decided to build my product cofounder **CandidAI**—what would eventually become Cutline.

I migrated from ChatGPT to Gemini for a few reasons:

1. **Familiarity**: I’ve already built TextGuardian in Firebase and Gemini and at this point I am very familiar with the stack.
2. **Customizabaility**: Vertex AI features for customizing models came in very handy for segueing from ‘Absolutely Right! AI’ to Candid AI.
3. **Cost efficiency**: For the volume of analysis I needed, Gemini was more cost-effective.

I built the backend on **Firebase** because:
- **Real-time updates**: I could see analysis results as they were generated
- **Persistence**: All my product analyses were stored and searchable
- **Scalability**: Firebase handles the infrastructure so I can focus on the product logic
- **Authentication**: Built-in auth for sharing analyses easily

## What CandidAI Became

What started as a set of prompts became a full product management suite:

- **Pre-mortem analysis**: Systematic risk identification across demand, channel, unit economics, operations, legal, and competition
- **Assumption tracking**: Explicit assumptions with validation plans and deadlines
- **Market analysis**: TAM/SAM/SOM calculations with rationale
- **Decision framework**: Go/No-Go recommendations with quantified confidence levels
-**Feature prioritization**: Automatic MoSCoW type analysis based on conjoint analysis ion specifically how that feature will help you convert, retain, or price

And an exciting feature coming soon: Cutline User Personas — what if we took a user story and used AI to make it interactive? A Cutline Persona is anchored to a specific set of desires, viewpoints, and behaviors to provide live feedback on products and features. 

Most importantly, CutlineAI is **pessimistic by default**. While most AI tools are overly optimistic cheerleaders, Cutline is designed to help you "murder your darlings" before you invest too much time and money.

I’ve been having a bit of fun having Cutline evaluate joke companies (Aplets&Cotlets.com is my idea for a subscription box that will ship Aplets & Cotlets anywhere in the world or on the ISS for $1 a month) and busted startups of the past (Juicero was a company that tried to apply DRM for some reason to cold-pressed juice). 

## The TextGuardian Lesson

Cutline was, shall we say, ‘quick to the cut’ with TextGuardian — Cutline's pre-mortem analysis was sobering. The system identified risks I'd been aware of but hadn't fully quantified:

- **User behavior friction** (users not forwarding messages)
- **Platform risk** from telco blocking (I’ve encountered this and have some work arounds but it’s outright killed some features that could have added value)
- **Unsustainable unit economics** due to high/unknown CAC

The analysis recommended **No-Go** with specific kill criteria. It wasn't what I wanted to hear, but it was what I needed to hear.

This isn’t a full pivot of TextGuardian, but a ‘pause and ponder’: at present, I think TextGuardian might be too early in the 2025 market (especially for a solopreneur with little consumer experience like myself) and might be ripe with some tweaks and developments for 2027 or 2028.  For now, TextGuardian remains a going concern and the software will be in Keeping The Lights On Mode, while in the meantime I am focusing on building tools like Cutline that will enable solopreneurs, startups, and engineering teams to build the next wave of applications.  

## Why This Matters

As a solo developer or small team, you don't have the luxury of a full product team. You need to make good decisions quickly. You need to identify icebergs before they’ve emerged. You need someone to challenge your assumptions.

That's what Cutline is: **a product coach that helps you make better product decisions**.

It started as ChatGPT prompts. It evolved into a full product powered by Gemini and Firebase. And it's saved me from building products and features that would have been dead on arrival.

*If you need a new approach to product development for the AI age, go to thecutline.ai/premium and enroll as one of the first members of our heavily discounted Founder Member cohort ($9.99 monthly/$99 annual)*. 


vibecoding

Not a PRD, Not a Plan, But a Secret Third Thing

Cutline or: How I Learned to Stop Pivoting and Love the Slop or: Why I Built a Product Cofounder