Your product truth shouldn't be trapped in code.
Stewie turns product intent (docs, stories, decisions) and code into a living behavior spec your whole team can trust and keep aligned over time — even with AI in the loop.
Most teams don't have a shared product spec. They have a codebase.
The real behavior of your product lives across docs, decisions, code, and people's heads — scattered, inconsistent, and invisible to everyone but you (and the AI tools you're trying to use).
Product logic lives in your head
You re-explain how your system behaves to new hires, contractors, outsourced teams, and AI tools constantly. There's no shared record of decisions.
Docs drift from day one
PRDs, wikis, and Confluence pages go stale within weeks. The only truth left is the code — and only you know how to read it.
Every new hire restarts from zero
Onboarding means reading thousands of lines of code with no behavioral reference — whether it's a new hire, a vendor team, or an internal tools handoff. Months pass before they're autonomous.
How It Works
Four steps from codebase to living behavior spec.
- 1
Start from what you have
Upload product docs (PRDs, user stories, decisions) or connect a repo read-only. Stewie builds a fast first product map, then you can add more evidence later.
- 2
Review the first product map
Stewie surfaces the strongest modules, behaviors, and open questions first. You see what looks solid, what is still unclear, and where trust needs work.
- 3
Trust, reject, or revisit
Review what matters, decide what you trust, and mark unclear areas for follow-up. Nothing becomes part of your behavior spec without your sign-off.
- 4
Build your product truth
Your trusted product map becomes a living behavior spec. Connect your repo later (optional) to keep it aligned as the code changes.
See It In Action
From codebase to product truth in minutes
Stewie reads your repo, surfaces what your product actually does, and outputs a spec your whole team can trust.
What Stewie Does
See what your product actually does. Decide what's true. Keep PRs aligned with intent.
Step 1 — Analyze
Stewie maps how your product actually works
Point Stewie at your sources (docs or code). It extracts behaviors and business rules into a plain-language product map — so your whole team can see what the product does, not just the people who wrote it.
Product Map — Candidates
12 files analyzed · High confidence
8 files analyzed · Medium confidence
Assumption: "Stripe is the source of truth"
Behaviors Found
3 routes may bypass this rule
Is the 14-day refund window a confirmed product policy or a temporary default?
Why we're asking
The code enforces a 14-day window, but there's no documentation confirming this as a product decision. Two team members have different assumptions.
Step 2 — Confirm
Your team decides what's true
Stewie surfaces what it found and asks plain-language questions. Anyone on the team — product owner, engineer, founder — can confirm what's right, reject what's wrong, and flag what's still undecided. No code knowledge required.
Step 3 — Specify
Product truth that stays current
Confirmed decisions become a living behavior spec — readable by your whole team, always in sync with the codebase. No more stale wikis or outdated specs that nobody trusts.
Behavior Spec
ConfirmedAuto Sign-out After Inactivity
Authentication · Confirmed by 2 team members
When
60 minutes pass without user activity
Then
- User is signed out
- User is redirected to login
- Security event is recorded
Last reviewed Mar 15 · Linked to 3 source files
Your team controls what's trusted
Anyone can confirm, reject, or defer each product behavior. Nothing becomes part of the spec until a human signs off.
Every claim traces back to evidence
Each behavior links to the code that supports it. When something changes, you know exactly which product decisions are affected.
Open format, no lock-in
Contracts are plain Markdown files in your codebase — readable by anyone, portable, and under your control. Not trapped in another tool.
Built on an open foundation
The PBC format is a public, vendor-neutral spec for behavior specs. Stewie is the product built on top of it.
Open format
The .pbc.md file format is a public spec. Your behavior specs are plain markdown — version-controlled, portable, readable without Stewie.
CLI + reference viewer
The spec ships with a reference CLI (validate, list, stats) and a browser viewer that renders structured PBC blocks as rich UI — state diagrams, behavior panels, actor grids.
Stewie is the product
Stewie's proprietary layer is the product map, trust workflow, and spec synthesis built on top of the open format.
The spec, CLI tooling, and reference viewer are live at github.com/stewie-sh/pbc-spec. The format is in active development — Stewie is built on it.
View the specBuilt for teams who read the fine print.
Security and data handling designed for production code with AI in the loop.
Read-only access
Never writes to your repo, opens PRs, or modifies code.
No model training
Your code never trains any model. Our commitment.
Manual analysis only
No background scanning. You trigger analysis, and only then.
Derived artifacts only
We store structure maps and summaries — not repo copies. Full data deletion on request.
Early beta access
We are onboarding a small group of product and engineering teams now. Beta scope, limits, and pricing may evolve as we learn.
Free Beta
Lightweight access · single-product evaluation
A lightweight path to evaluate the core workflow and join the beta queue.
- —1 product, up to 3 modules
- —Markdown PBC export
- —1 guided product map
- —Trust review workflow
- —Traceable evidence
- —You own the resulting .pbc.md files
- —Access scope may evolve during beta
Founding Design Partners
Paid early access · founder feedback loop
Deeper access, closer collaboration, and direct input into what gets built next.
Everything in the beta waitlist path, plus:
- —Paid early access
- —Expanded beta access for deeper usage
- —Multiple analyses during the beta period
- —Shared behavior spec review access
- —Versioned spec workflow
- —Priority access to Standard Library modules as they open up during beta
- —Priority support + direct founder feedback channel
- —Shape the roadmap before public launch
Team
Multiple products · shared workspace
For teams that need shared product intelligence across multiple products and roles.
- —Multi-product workspace
- —Team-wide behavior specs
- —Shared review and sign-off workflows
- —Role-based access for PMs, engineers, and QA
- —Priority onboarding and setup support
Beta scope, limits, and future pricing are still evolving.
Stewie is not a coding agent. Not a wiki.
Coding agents write code. Wikis document intent. Stewie connects the gap — a living spec grounded in what your code actually does.
Copilot, Cursor, and Devin generate implementation fast.
Stewie captures what the code means. Coding agents write — Stewie makes explicit the intent and behaviors behind what was built, so reviews stay grounded in product truth.
PRDs and wikis explain what you planned. They drift the moment code ships.
Stewie produces a living spec grounded in your actual codebase — every claim backed by file-level evidence.
Jira, Linear, and Notion track work. They describe what you plan to build, not what actually runs.
Stewie captures verified product behavior — what your code actually does today, with evidence you can trace.
From the blog
Thinking on product behavior
Design partners wanted
Your product truth deserves to be explicit.
We're onboarding a small group of product and engineering teams before public launch. Shape the product. Get in as a Founding Design Partner during early beta.