Why Pitches exists
Before Pitches, documents lived in email threads, Sharepoint folders, and local drives. Nobody knew which version was current. Developers got outdated specs. BAs wasted time answering "where's the latest BRD?"
Pitches gives every document a permanent, canonical URL. Upload a new version and everyone with the link sees it immediately — no re-sharing, no "v2_final_FINAL.docx".
Features
Documents & viewing
Canonical URLs — Every pitch gets a short, permanent link (pitches.greatbuildersolutions.com/42). Share it once; it works forever. New versions appear automatically at the same URL.
In-browser viewer — Open any .docx directly in the browser with full fidelity: images, tables, headers, footers, and page layout preserved. No download required.
Version control — Every upload creates a new version (v1, v2, v3...). Previous versions are never overwritten. A slide-out drawer shows the full history — who uploaded, when, and what changed. Click any version to view inline or download individually — legacy DOCX versions download as-is, and structured-content versions are rendered back into a DOCX on demand from the copy saved with that version, so an earlier version always opens exactly as it was saved. Versions can be deleted from the drawer, but not once the pitch is read-only (Deployed or Rejected), and not while an active approval depends on them.
PDF & DOCX download — Download any pitch as a formatted PDF (title page, sections, images) or DOCX. Both keep the editor's formatting: headings, bold and italics, bullet and numbered lists, tables, links and inline images. Final pitches default to PDF; in-progress pitches default to DOCX. Every PDF page carries a "Page X of Y" footer, and PDFs made from an uploaded Word document keep that document's own running header and footer, page numbers included.
Large file support — Files up to 100 MB are supported. Small files (under 4 MB) upload directly; larger files route through Azure Blob Storage transparently. Uploaded images are automatically optimized to reduce storage.
Smart URL resolution — Use legacy identifiers you already know:
/sr-51442 → finds the pitch with SR #51442
/scr-51442 → same (SR and SCR are interchangeable)
/db-1234 → finds the pitch tagged with Linear ticket DB-1234
/gi-1064 → same for any team key (GI is Business Central, RP is GGRP)
One match redirects to the canonical URL. Multiple or no matches land on the dashboard with the search pre-filled.
Creating & importing
Create a pitch — Click New Pitch, drag in a .docx, and AI extracts the title, description, and legacy identifiers automatically. No forms. You get a canonical URL to share immediately. Real-time streaming progress shows each stage as it completes.
Duplicate check — Before a file lands, it is compared against existing pitches by file content, ticket key, legacy identifiers (SCR/SR/FS/DB), and title. Anything that looks like a match is held for your confirmation, with links to the matching pitches so you can compare. If it is genuinely a different pitch, click Create anyway; if it is a new version of an existing pitch, upload it from that pitch's page instead. A byte-identical file can never become a separate pitch, so that card only offers the link. If the document type can't be determined confidently, choose Upload as pitch or Upload as BRD. The ticket key (Linear or Jira — DB-4467, RP-162, AI-253) is read from the filename first, then from the document header (above the Problem section). Tickets mentioned in the body, such as dependencies, are ignored.
Bulk BRD import — Upload multiple .docx files at once, drag to reorder (pitch numbers assigned by order), and fill in legacy metadata per file. Import runs sequentially with a live progress bar.
Version-grouped import — When importing multiple versions of the same document (e.g. BRD - Project_V1.0.docx, _V1.1.docx, _V1.3.docx), the app detects the version pattern and groups them automatically. Instead of creating separate pitches, it creates one pitch with multiple versions. The AI extracts metadata from the latest version. Supported patterns: _V1.0, _V2, _v3, (V1.0), _Rev2.
BRD-to-Pitch coaching — Convert legacy BRDs into shaped pitches using the gbs-pitch-coach plugin. The Convert to Pitch button launches an interactive coaching session in Claude Code or Cowork that walks through all eight Shape-Up sections, drafts collaboratively, and uploads the result as a new version. Saving that shaped content relabels the document from BRD to Pitch, so the BRD badge and Convert button disappear.
Editing & collaboration
Inline editor — Edit pitches directly in the browser. Rich text with formatting tools, organized into Shape-Up sections (Problem, Appetite, Solution, etc.). Upload images inline. Changes save atomically. Both structured and legacy DOCX pitches coexist.
Inline comments — Select text to leave an anchored comment. The comment box opens right beside the selected text and follows it as you scroll; on a phone the comment form opens across the top of the screen, clear of the keyboard. Comments are highlighted in the document and tracked in a sidebar with All, Unresolved, and Resolved tabs, listed in the order they appear in the document. A badge shows unresolved count at a glance. Click a highlight in the document, or a comment in the sidebar, to focus it at the top of the sidebar: the anchored text scrolls into view and briefly flashes — Word-style — and the sidebar's previous/next arrows (or ↑/↓, j/k) step through the remaining comments in reading order. Reply to any comment to start a threaded conversation; the original author is notified even if they haven't subscribed yet. Approval notes left when signing off a pitch appear at the top of the comments sidebar alongside the discussion.
AI features
Change summaries — When you upload a new version, AI compares it to the previous one and generates a plain-English summary. The summary is editable before confirming.
Pitch review — Click Get AI Feedback for a structured review against the Shape-Up template. Claude analyzes text and embedded images, scoring each section:
| Section | What it checks |
|---|---|
| Problem | Concrete pain point? Who's affected? |
| Appetite | Time budget set? Appropriate scope? |
| Solution | Rough, solved, and bounded? Sketches included? |
| Rabbit Holes | Complexity risks called out? |
| No-Gos | Firm boundaries set? |
| Nice to Have | Stretch goals separated from core? |
| Acceptance Criteria | Testable and comprehensive? |
| Approvals | Sign-off section present? |
Each section gets good, needs work, or missing with specific feedback.
Title naming rules — Configurable rules (in Settings) control how titles are cleaned across all AI extraction, Monday sync, and re-extract flows:
| Rule | What it does |
|---|---|
| Strip patterns | Regex patterns for noise to remove (e.g. ^SCR#\d+\s*, ^BRD\s*[-–]?\s*) |
| Module codes | Dynamic Builder prefixes to preserve at the start (e.g. SO, JC, PD, SM) |
| Max length | Target maximum title length (default 80) |
Examples:
| Before (raw from Monday/AI) | After (cleaned) |
|---|---|
SCR#6783 SO View Floorplan Usage – enhance report | SO View Floorplan Usage - Enhance Report |
BRD – SCR#6653 - SR#72562 – JC Update Item Statuses | JC Update Item Statuses |
SM>Takeoff – Add Restrictions Filter | SM Takeoff - Add Restrictions Filter |
AW/SL Amalgamation: BRD - Takeoff Junction | AW/SL Amalgamation: Takeoff Junction |
The AI is given these rules when generating titles, so extracted titles follow the format from the start.
Status & workflow
Status lifecycle — Every pitch moves through a configurable pipeline:
Draft → Dev Review → Requestor Review → Approved
Two special statuses available at any stage: Hold (reversible pause) and Rejected (terminal). Status changes are one-click with full audit trail. Approved and Rejected enter read-only mode. The pipeline is editable from Settings.
Approval gates — Moving a pitch from Dev Review → Requestor Review → Approved requires sign-off from the right person at each gate. Developers approve the dev gate; the requestor approves the requestor gate. Approvals are recorded against the current version — uploading a new version invalidates them, so reviewers always sign off on what they actually saw. Deleting a version is blocked while an active approval is stamped to it — or to a version above it, since deleting renumbers those — so revoke the approval first. Deleting the version that caused an invalidation is allowed, and restores the prior approvals and status automatically, since reviewers already signed off on that exact content — restored approvers get notified their sign-off is back in force (mutable in notification preferences). Anyone with revoke permission can revert a gate, which moves the pitch back to the prior status. The approvals panel's sign-off history (who, when, on which version) is split into two sections: Version History for approvals still tied to a current version number, and Deleted Versions for past approvals whose version has since been deleted. Because a version can't be deleted while an approval on it is still active, entries only ever reach Deleted Versions after already being superseded or revoked; they're struck through, dated by when the version was deleted, and the split keeps them from being confused with the live approvals that inherit their old version numbers.
Reverting from a final status — Admins can move a pitch back out of a final status (e.g. Deployed) to an earlier stage, for cases where it was closed out in error or needs further work. Revert to buttons for each earlier stage appear on the detail page for any final-status pitch. Reverting to Approved specifically is only accepted while both approval gates — and any assigned extra reviewer — are still signed and not revoked, and the pitch is not on hold; otherwise the request is rejected with an explanatory error. On the kanban board, dragging a card out of a final status asks for the same confirmation before anything is sent. Reverting to an earlier stage (Draft, Dev Review, Requestor Review) has no such requirement.
Extra reviewers — Some projects need more than two approvers. Click Reviewers on a pitch to assign one additional reviewer to either the Dev Review or Requestor Review gate. The extra reviewer must also approve before the gate advances — even after the primary approver signs off, the pitch waits at the gate until both approvals land. Picked from the same team directory as other role assignments; revoking the extra approval reverts the gate just like a primary revoke. Each pitch supports one extra reviewer at a time — reassigning automatically invalidates the previous one (with an audit-trail entry). The assignment is hidden once the pitch passes the gate it was set for, so you can't accidentally assign someone to a stage that's already done. Available to editors and admins on any non-final pitch.
Monday.com integration — Bidirectional sync with Monday.com. Pitches are matched to a board item by Linear ticket key first, then by SR/SCR number, across the boards enabled in Settings (AW DB Requests, GG DB BRDs, AW BC Requests, GG BC Requests). The number is found even when the item's SR# cell lists several references, such as 125981/SCR#6842. If it appears on more than one item, the pitch is left unlinked rather than guessing. Once linked, a pitch stays with its item: status changes go to that item even if the item is later archived or the pitch's ticket key or SR number would now match a different one, and a ticket key added to the item's Linear column is copied onto a pitch that has none the next time a status change passes between them.
| When | Direction | What happens |
|---|---|---|
| You change status in Pitches | Pitches → Monday | Monday item updates to match |
| Someone changes status in Monday | Monday → Pitches | Pitch updates to match (via webhook). A Monday change that arrives late never overrides a newer status change |
| New pitch created with a Monday link | Monday → Pitches | Pitch inherits Monday's current status |
| You click Link to Monday or Sync with Monday | Furthest along wins | When neither side is on hold or Rejected, whichever side is further along the pipeline updates the other, so neither is moved back to an earlier stage. A Deployed pitch closes its Monday item only if the pitch changed since the last sync. When either side is on hold or Rejected, the pitch wins if it changed since the last sync; otherwise (and always on a first link) the pitch takes Monday's status, so a pitch on hold comes off hold and can move back to an earlier stage. A pitch on hold or Rejected and a Closed Monday item are both left as they are |
Title sync applies the naming rules above to keep titles clean across both systems. On a new pitch, the linked Monday item's name is preferred. When you click Sync with Monday, a pitch title that already follows the rules is kept and copied to the Monday item; a title that does not is reconciled with the Monday name.
The detail page shows Monday linkage state for any pitch with a ticket key, an SR number or a Monday link:
- Linked — red dot indicator, direct link to Monday item, last sync time
- Not linked — item wasn't found on any board
- Not yet checked — linkage hasn't been verified yet
The red dot also appears on kanban cards and grid view. Board eligibility is configurable in Settings.
Notifications
Notification center — Bell icon in the header shows unread count. Click for recent activity (status changes, comments, uploads, reviews, edits). Click any notification to jump to the pitch. Notifications are kept for 90 days.
Subscriptions — Auto-subscribed to pitches you create, change status on, or comment on. Manual subscribe/unsubscribe via the Subscribe / Watching button on any pitch.
Email — Opt-in email notifications for status changes, new comments, replies, new versions, and AI reviews. Comment and reply emails include the full comment text as a quote block so you can read it without opening the pitch. Every email includes an unsubscribe link. Configure which events trigger email from notification preferences (gear icon in the notification dropdown).
Integrations
MCP server — The app exposes an MCP server at /api/tools/mcp with 26 tools and 5 resources. Two workflows:
- Developers use Claude Code to interact with pitches from the terminal
- BAs use Cowork with the
gbs-pitch-coachplugin for interactive pitch coaching
Connect from Claude Code:
claude mcp add --transport http pitches https://pitches.greatbuildersolutions.com/api/tools/mcp
Connect from Cowork: admin adds the connector org-wide via Settings > Connectors > Add custom connector with the URL and Okta OAuth credentials.
The existing get_version_file tool also supports delivery: "download" for a
short-lived file link that Cowork can save in its working folder. It retains the
existing version and approval policy, returns the file size and SHA-256 for
verification, and leaves base64 as the default for other clients. No additional
BA connector is required. Details for developers: specs/mcp-version-download.md in the repository.
Telemetry — Server-side telemetry via Azure Application Insights. Auto-collects HTTP requests, outgoing dependencies, and exceptions. Custom events track pitch creation, status changes, uploads, reviews, syncs, and edits. Disabled when APPLICATIONINSIGHTS_CONNECTION_STRING is unset.
Dashboard — Searchable, filterable grid of all pitches. Search by title, number, or any legacy identifier. Filter by status. Sort by recently updated, number, or status.
Admin tools
Role impersonation — Admins see a Viewing as dropdown in the top bar. Switching to Developer, Editor, or Viewer changes the effective role applied to both the UI and server-side API calls, so role-gated features can be tested without signing in as another user. A banner across the top of every page makes the impersonated state obvious and offers a one-click exit. The underlying account stays admin — only the effective role changes.