Six places this build reads as org-ready today but is deliberately simplified underneath. Each one names the honest gap, not just the feature.
Gap 1
A “Viewing as” role picker in the app header changes what's usable across the whole app: only an Approver can mark a PRD approved, only a PM or Lead PM can edit or regenerate content. The choice lives in your browser, not tied to any real account, and nothing on the server checks it.
A real organization table with actual member roles, enforced on the server rather than hidden in the UI, tied to real identities through SSO or a Google Workspace domain instead of a toggle anyone could flip back.
A role that only lives in the browser isn't a permission system, it's a preview of one. The moment this needs to hold up for an audit or a compliance requirement, the check has to move to the server.
Gap 2
The Jira issues and Confluence pages you can browse here are real, pulled once from an actual Atlassian workspace and saved as static fixtures. There's no live connection, and no way to write the finished PRD back into Jira or Confluence.
A real per-organization OAuth connection, live reads scoped to that org's own projects and spaces, and a write path that posts the generated PRD back where the team already works.
Nobody wants to re-upload documents that already live somewhere else. The value of an integration like this is the two-way connection, not the read-only preview.
Gap 3
Standard, Lean/MVP, and Enterprise/Compliance-Heavy are three fixed section layouts, written into the code. Picking one at project creation changes which sections show and in what order.
A real template editor, where an admin can add, remove, and reorder sections for their own organization, saved per organization instead of hardcoded into the app.
Every team's PRD format is a little different. Three presets prove the idea works. An admin-configurable editor is what makes it worth an organization actually adopting.
Gap 4
Draft, In Review, and Approved are a plain label on each version. The Approver role narrows which choices show up in the dropdown, but nothing on the server checks who's actually setting it.
A status change enforced by the same real role table described above, plus a record of who approved what and when, since that's the part an actual review process depends on.
“Approved” only means something if it's provably tied to a specific person, at a specific time, who actually had the authority to say so.
Gap 5
Every attribution chip is a best-effort match: how much a generated claim's wording overlaps with a source chunk. It works well at the scale this prototype runs at, a handful of documents per project.
A real embeddings-based vector search once a project's source library grows past what word-overlap matching can meaningfully rank.
This one was named as an explicit non-goal from day one, not a corner cut discovered later. Worth saying so directly rather than letting a small-scale trick quietly stand in for a search system.
Gap 6
Access control here is a single email allowlist and a personal run cap, sitting inside one shared Supabase project. There's no organization boundary anywhere in the schema.
An actual organizations table, every row scoped to a tenant instead of just a user, SSO or domain-restricted sign-in instead of a hand-maintained allowlist, and usage limits set per organization instead of one global number in an environment variable.
This is the real distance between a working single-user prototype and a product an actual company could safely turn on for its whole team.