ChatPRD and Stonewall both use AI to help product teams write better specs. Both have loyal users. Both solve real problems. But they approach spec writing from fundamentally different starting points, and understanding that difference matters more than any feature comparison chart.
Here's an honest breakdown.
What ChatPRD Does Well
ChatPRD is a conversational PRD generator. You describe a feature, answer a series of guided questions, and it produces a structured product requirements document. The experience feels like working with a senior PM who asks the right follow-up questions.
Conversational workflow. ChatPRD doesn't hand you a blank page. It walks you through the spec, prompting you to think about user personas, success metrics, edge cases, and acceptance criteria. For PMs who struggle with blank-page paralysis, this is genuinely valuable.
The "How I AI" community. ChatPRD has built a community around AI-assisted product management. Users share prompts, workflows, and spec templates. This creates a feedback loop where the tool improves based on collective PM experience, not just the product team's roadmap.
Product-first thinking. ChatPRD excels at the product layer of specs. It pushes you to define the "why" before the "what" — jobs to be done, user outcomes, success criteria. The output reads like a document written by an experienced PM, because the tool embeds PM methodology into its conversational flow.
Template variety. Whether your team uses Amazon's PRFAQ format, a lean one-pager, or a detailed engineering-ready spec, ChatPRD has templates that match. This flexibility makes it adoptable across different organizational cultures.
What ChatPRD Doesn't Do
ChatPRD generates specs from your conversation. It knows what you tell it. It doesn't know what your codebase looks like.
When you say "add a notifications feature," ChatPRD will ask smart product questions: Who receives notifications? What triggers them? What channels (email, in-app, push)? How do users manage preferences?
It won't ask: Does your codebase already have a notification service? What does your event system look like? Is there an existing notifications table, or does this require a new entity and migration? Which WebSocket infrastructure, if any, is already in place?
ChatPRD can't ask these questions because it doesn't have access to the answers. The spec it produces will be a well-structured product document that an engineer still needs to mentally map onto the actual codebase.
What Stonewall Does Differently
Stonewall reads your codebase before generating specs. When you describe a feature, Stonewall knows your database schema, your API routes, your component hierarchy, your existing patterns, and your migration history.
Codebase-grounded specs. When you say "add notifications," Stonewall responds with awareness: "Your codebase has an EventEmitter pattern in src/events/ used by three existing modules. The users table has an email_verified column that should gate email notifications. There's no existing notifications table — this requires a new entity extending BaseEntity with a migration." The spec references real files, real patterns, real constraints.
Conflict detection. Stonewall identifies when a proposed feature conflicts with existing code. A new column name that collides with an existing one. A new API route that overlaps with middleware rules. A proposed state management pattern that contradicts the existing architecture. These conflicts surface in the spec, not in code review three weeks later.
Schema-aware acceptance criteria. Instead of generic acceptance criteria ("user can see their notifications"), Stonewall generates criteria grounded in the data model: "GET /api/notifications returns PaginatedResponse<NotificationResponseDto> with read, unread, and archived filters. Each notification includes entityType and entityId for deep linking."
File-level implementation guidance. The spec includes which files need to change, which patterns to follow (based on how similar features were built in the codebase), and which tests need updating. Engineers don't need to do the mental mapping — it's already done.
The Honest Trade-Offs
Where ChatPRD Wins
- Pure product thinking. If your goal is to sharpen the product narrative — the user need, the market context, the success metrics — ChatPRD's conversational approach is stronger. Stonewall's codebase focus means it's better at the "how" than the "why."
- No setup required. ChatPRD works immediately. Stonewall requires connecting your repository, which means security review, access configuration, and onboarding.
- PM accessibility. ChatPRD is designed for PMs who may not be technical. Stonewall's output includes code references and schema details that assume some technical fluency.
- Greenfield projects. If you're writing specs for a product that doesn't exist yet, ChatPRD's methodology-driven approach provides more value than codebase awareness of a codebase that doesn't exist.
Where Stonewall Wins
- Spec-to-implementation accuracy. The spec reflects the actual system. Engineers don't need to reinterpret product intent through the lens of technical reality — the spec already accounts for it.
- Estimation accuracy. Because specs surface the real scope of changes, engineering estimates are grounded in files and patterns rather than abstract feature descriptions.
- Reduced back-and-forth. The questions that would normally come up in sprint planning ("did you know our auth works like this?") are answered in the spec itself.
- Mature codebases. The more complex your system, the more value codebase awareness provides. A simple CRUD app doesn't need this. A system with 50 entities, middleware chains, and cross-cutting concerns does.
When to Use Which
Use ChatPRD when:
- You're defining a new product or feature area from scratch
- The spec is primarily a product strategy document (PRFAQ, opportunity assessment)
- Your PM team is non-technical and needs guided workflows
- You're in early discovery and the implementation details are premature
Use Stonewall when:
- You're writing specs for changes to an existing codebase
- Spec-to-implementation gaps are causing missed estimates and rework
- Engineers have started ignoring specs because they don't reflect technical reality
- You need specs that engineering can execute without extensive translation
Use both when:
- You use ChatPRD to define the product layer (user need, success criteria, scope) and Stonewall to generate the technical spec layer (schema changes, API contracts, file modifications). This combination gives you well-structured product thinking grounded in codebase reality.
The Bottom Line
ChatPRD and Stonewall aren't really competitors. They operate at different layers of the spec. ChatPRD helps you think like a better PM. Stonewall helps your specs understand your code. The question isn't which tool is better — it's which gap is costing your team more right now.
If your specs are strategically weak, start with ChatPRD. If your specs are strategically sound but technically disconnected, start with Stonewall. If you want the full stack, use both.