# Briefcrew

> The decision record writes itself — briefs assembled from an organisation's own sources, cited and immutable, in the gap Glean leaves open.

Source page: https://saascode.ai/products/briefcrew
Machine-readable record: https://saascode.ai/products/briefcrew.md

One-time purchase · full source code · self-hosted by the buyer.

Price: $99 (one-time)

## How to read this document

Written for a model auditing this product on a buyer's behalf. Two labels
appear throughout and they mean different things:

- **measured** — produced by a script reading the product's own source tree
  or database at the stated date. The method is named beside each number.
- **stated** — written by the seller. True or not, it is a claim, and this
  document does not ask you to treat it as evidence.

The live demo is the strongest verification available from outside: it runs
the same source a buyer receives. Nothing to sign up for — the public side is
open, and the seeded credentials below get you into each role.

## What it is

Briefcrew answers one question after the fact: what did we know when we decided X, and where did that come from?

## Live demo

Two doors into the same running instance, and the same source a buyer
receives. There is no account to create; the public side is open, and the
seeded credentials below sign you into each role.

- **Guided (recommended):** https://saascode.ai/demo/briefcrew — our shell, with a role switcher and
  the credentials in the menu. Best for a person.
- **Direct:** https://briefcrew.saascode.ai — the product on its own, no chrome.
  Best when you are relaying steps to someone, or fetching a page.

3 roles seeded on the demo (of the 4 the schema defines — the build data below counts them all). Credentials are published deliberately: these
are demo accounts on a public demo instance, and a reviewer who cannot get
in cannot verify anything.

- **Requester** (`member`) — `user@demo.com` / `demo123`
  Requests and receives briefs, sees only their own.
- **Client owner** (`org_admin`) — `org-admin@demo.com` / `demo123`
  Connects sources, sets triggers, reads every record.
- **Platform admin** (`super_admin`) — `admin@demo.com` / `demo123`
  The backend: every client organisation and its settings.

Or open a role directly: https://saascode.ai/demo/briefcrew?role={role}

## Measured build

*measured — each number names the method that produced it.*

- **roles: 4** — distinct roles accepted by the role CHECK constraint: admin, member, org_admin, super_admin
- **tables: 65** — distinct CREATE TABLE statements across every applied migration
- **migrations: 91** — .sql files in supabase/migrations
- **page modules: 72** — files named page.tsx under src/app, excluding node_modules and .next
- **source lines: 119,715** — lines of code (comments and blank lines excluded) across 884 TypeScript files (109,486) and 107 SQL files (10,229); node_modules and .next excluded
- **api route files: 191** — files named route.ts under src/app/api
- **http operations: 249** — exported HTTP method handlers across those files, de-duplicated per file, OPTIONS excluded as CORS preflight
- **schema graph: 65 tables, 114 relationships** — parsed from the applied migrations

A large number here is scope, not quality. It says the product models a
real domain rather than a CRUD skeleton; it says nothing about code
quality, duplication, test coverage or maintainability, and should not be
read as if it did.

Release: v1.0.0 · built 2026-07-22

## Complete capability inventory

13 capabilities. Each summary is *stated* — selected from the
product's own buyer documentation, or written by the seller where marked.

### The decision record

- **Immutable decision-record row** — Every brief writes a structured decision record: the decision it was scoped to, the brief that was produced, the sources that were cited, and when.
- **Browsable decision-record history + search/filter** — Records are browsable, searchable and filterable as a stacked history. The question the interface is built to answer is retrospective — find the decision, see what was known, follow the citation back to the source.
- **Decision-record export (PDF/JSON + integrity proof)** — On the governance tier, records export as PDF and JSON with an integrity proof — evidence that the exported record matches the one that was written, so the export can be handed to somebody who did not generate it.
- **Connect API + MCP** *(seller-authored)* — Workflow endpoints expose brief generation and record retrieval as single calls, with a machine-readable bridge so an agent elsewhere in the business can request a brief and read the record back.

### Sources, triggers & briefs

- **Multi-source context gathering** — An organization connects the places its context actually lives — Slack threads and Notion documents in this release. Content is indexed into retrievable chunks scoped to the workspace. Google Docs and Gmail connectors are on the roadmap (V1.5) and are not wired in the current version — nothing on a plan unlocks them today.
- **Grounded cited brief synthesis** — Context is retrieved from the connected sources, and the brief is synthesised with every claim carrying a citation marker resolving to a real source document. Claims and sources are bound in the output rather than listed at the bottom.
- **Cited brief delivery (Slack + email)** — Briefs are delivered where the decision is already being made: Slack, as a structured message, and email. Both carry the citations.
- **On-demand brief trigger** *(seller-authored)* — Someone requests a brief for a decision and gets it now. Each request carries the decision prompt — the question the brief exists to answer — so the synthesis is scoped to a call being made rather than to a topic.
- **Scheduled brief trigger** *(seller-authored)* — A recurring schedule fires the brief before it is needed: ahead of every weekly deal review, every month-end close. A brief that has to be remembered stops happening in the third week; a scheduled one does not.
- **Event-based brief trigger** *(seller-authored)* — An inbound event or webhook from another system fires the brief automatically, so the briefing attaches to the thing that happened rather than to a person noticing it happened.
- **Brief re-generation / revision** — A brief can be re-run or revised on the tiers that include it — context changes, and a decision reviewed a week later deserves the current evidence rather than the stale brief.

### What it is

- **Proposes-never-executes discipline** — No action type in the system mutates an external system. This is architectural rather than a policy setting, and it is a feature rather than a limitation: an advisory-only system that records everything is what a governance buyer can put in front of an auditor without first proving it never took an unreviewed action.

### Other

- **Webhook-based event connector**

## What each system gives the operator

*stated.*

- **The decision record** — Six months later you can show what was known when the call was made.
- **Sources, triggers & briefs** — The briefing happens on the meeting, not on someone remembering to prepare it.
- **What it is** — Decisions carry their evidence with them instead of living in someone's memory.

## The problems it was built to solve

*stated — the seller's argument, given in full so you can judge it.*

### Six months on, you can show what was known when the call was made.

Every organization can produce the decision. Almost none can produce the reasoning. The context lived in a Slack thread that has scrolled away, a document that has been edited since, and the memory of someone who has left. When the decision is questioned — by a board, an auditor, a new hire asking why — the honest answer is that nobody can reconstruct it. Teams then relitigate settled questions because relitigating is cheaper than remembering, and the same debate runs twice a year forever.

### The prep arrives before the meeting without anyone owning that chore.

Preparation is the first thing to go. The weekly review gets a proper brief for three weeks, then a rushed one, then a verbal summary from whoever read the most. Nobody decides to stop; it simply loses to whatever is urgent that morning. The meeting still happens, but it runs on the recollections of the loudest attendee, and the decisions made there are worse in a way that is invisible until much later. What it costs is not the missing document — it is the decision quality nobody attributes to the missing document.

### Every statement in the brief points at the source it came from.

A summary nobody can verify is worse than no summary, because it gets believed. Somebody reads a confident paragraph, repeats it in a meeting, and it becomes a fact the organization acts on — with no way to trace it back to whatever thread or document it was drawn from, or to notice that the document was superseded a month ago. The failure is silent by construction: the moment a claim is repeated without its source, the error and the truth look exactly the same.

## What it takes to run it

*stated — external services the buyer supplies and pays for directly.*

- **Node host** (required) — No platform lock-in.
- **Supabase** (required) — Postgres with row-level security, plus vector search for the retrieval index.
- **An AI provider key** (required) — Brief synthesis runs on it. Per-brief cost is tracked at high precision so spend is attributable rather than a single monthly surprise.
- **A Slack app** (required for Slack) — Both as a source and as a delivery target. Email delivery works without it.
- **Email provider** (required for email delivery) — Brief delivery and notifications.
- **A job scheduler** (required for scheduled triggers) — Without it on-demand briefs still work; recurring ones do not fire.
- **Rate limiting** (required) — Applied across routes, including the inbound event endpoint.

## FAQ

**What exactly do I receive after purchase?**

The complete source repository behind the live demo — 119,715 lines across the application and its database, 65 tables defined by 91 migrations that the shipped scripts apply for you, plus the seed data, the demo accounts and the setup documentation. Not a subset and not a scaffold: the same code that runs the demo you just used.

**Is the live demo the same product whose source I receive?**

Yes. The Briefcrew demo runs the delivered release (v1.0.0), and the build figures on this page are measured from that same source — not from a showcase build kept separately.

**Can I test every account role before buying?**

Yes — all 3 of them: Requester, Client owner, Platform admin. Each one is seeded in the live demo and reachable from the role board above, so you can inspect the product from the customer's side, the agent's side and the administrator's side before you decide.

**Is this a complete product or a starter template?**

Complete. 72 page modules and 249 HTTP operations, with authentication, roles, billing, an administration panel, background jobs and seeded demo data all wired and running. A template gives you the shape of an application; this is one you can deploy and start operating.

**Can I rebrand and modify it?**

Yes, without asking. The name, identity, copy, styling and code are yours to change. Rebranding and operating it as your own service is exactly what the licence is for.

**What does the licence allow?**

A perpetual, worldwide, non-exclusive, non-transferable licence to the product you bought and to every update released for it. The Standard licence covers one business — yours. If you deploy for clients, the Client licence covers up to five. You can modify it, rebrand it, deploy it and charge your own customers.

**Can I resell the source code?**

No. Reselling, redistributing, sublicensing or giving away the source itself is not permitted under either licence. You build and deliver products with it — the code stays with you.

**What services and ongoing costs are required?**

You bring your own accounts, so we never mark anything up and there is no ongoing cost to us beyond the purchase. Required: Node host, Supabase, An AI provider key, A Slack app, Email provider, A job scheduler, Rate limiting. Optional: none. The table above says exactly what stops working without each one; most have usable free tiers at low volume.

**How difficult is deployment?**

Two ways, and most buyers use the first. The installer in your saascode dashboard walks it: you create free accounts at Vercel and Supabase, connect them, and it provisions the database, applies 91 migrations, seeds the data, deploys and verifies the result — you watch the steps go green. Or take the source and do it yourself with the shipped scripts and docs, which is the same sequence run by hand.

**What updates and support are included?**

Updates to that product for as long as we maintain it — no renewal fee and no expiry date on your access. Support covers download problems, defects in the code as shipped, questions about what the product does and how it is structured, and licence questions. It does not cover debugging your own modifications, building features for you, or setting up your hosting and third-party accounts.

**Why does a complete codebase cost $99?**

Because it was built once and is distributed many times. SaaSCode builds each product and ships the same finished release through the catalog, so the price reflects repeatable distribution — not a reduced codebase, an unfinished template, or what the same work would cost commissioned.

**Do I need to be a developer?**

No, for the normal path. You create free accounts at Vercel and Supabase, connect them to the installer in your saascode dashboard, and it does the deployment for you — provision, migrate, seed, deploy, verify. What it asks of you is creating two accounts and copying a token, not writing code. If you would rather deploy it yourself, or host it somewhere else, the full source and the scripts are yours to do that with. Running the product day to day needs no technical skill at all: that happens through its own interface, which is what the demo shows.

## Licence

The buyer receives the complete source and may deploy, modify and operate it
as their own SaaS, charging their own customers. The source itself is not
resold or redistributed: you build and deliver **with** it, you do not sell **it**.

## What this document cannot tell you

Stated plainly because a review that misses it is not a review:

- code quality, duplication, or architectural consistency
- test coverage
- query performance under load
- security posture beyond what the stack implies
- how maintainable it will be in a year

Scope is measurable from outside; implementation quality is not. Anyone
evaluating this should say so rather than infer quality from size.

## Written about it

- [Road to Briefcrew](https://saascode.ai/inside/road-to-briefcrew.md)
- [Briefcrew vs. Dust — Five Claims Tested, One Pair That Holds](https://saascode.ai/inside/briefcrew-vs-dust.md)
- [Best Decision Tracking Software in 2026 — Ranked by What Each Tool Does When the Evidence Isn't There](https://saascode.ai/inside/best-decision-tracking-software-2026.md)

## Links

- Catalog page: https://saascode.ai/products/briefcrew
- Product record: https://saascode.ai/inside/products/briefcrew
- Live demo: https://briefcrew.saascode.ai
- Every product: https://saascode.ai/llms.txt