Live workflow implemented. Explore the recorded example or the live preview — Plan 02 real-account qualification is pending.See the roadmap

Try the example

The moment before you build

Great decisions deserve a room.

Bring your toughest question to a team of AI advisers. They examine the evidence, challenge the plan and keep their objections on the record. You make the call.

Explore the recorded exampleSee a decision change
  • Qualified on macOS (Apple silicon), Windows x64 and Linux x64
  • No account, API key or model download for the example
Your models. Your roles. Your call.An illustration of an advisory room. Example seats for Product, Engineering, Market, Logistics and Finance surround the table; the human CEO sits at its head.YOUR MODELS.YOUR ROLES.YOUR CALL.PRODUCTENGINEERINGMARKETLOGISTICSFINANCEYOU, THE CEO

Illustration of the vision. Seats are examples.

BOARDROOM | Recorded example — scripted fictional fixture; no model calls.

[proposal] Product Owner | Fictional model A — scripted fixture
Proposal v1: launch five integrations and self-service billing in four weeks.

[objection] Lead Developer | Fictional model B — scripted fixture
Two engineers cannot credibly deliver that scope in four weeks. Start with one integration and a supervised pilot.
Evidence: context.md:4-4

[objection] Marketing Manager | Fictional model C — scripted fixture
The acquisition channel is unvalidated. Invite five design partners before funding a public launch.
Evidence: context.md:6-6

[revision] Product Owner | Fictional model A — scripted fixture
Proposal v2: one integration, supervised onboarding, and five design partners. Defer self-service billing and the public
 launch.

[final-views] Marketing Manager | Fictional model C — scripted fixture
Final views on v2: Product Owner APPROVED; Lead Developer APPROVED; Marketing Manager INSUFFICIENT_EVIDENCE. Willingness
 to pay remains untested. Human decision: pending.

Actual screen text from the packaged CLI in an OS pseudoterminal. The dialogue and model labels are fictional; playback makes no model calls. Capture provenance

Before the first line of code, there is a decision.

You can see the product. You can imagine the launch. Then come the questions that follow you long after you close your laptop.

  • Is this the right problem?
  • Can we deliver it?
  • Will anyone care enough to pay?

For a technical founder, those questions often land on the same desk. Yours. Boardroom begins at that moment.

The room

Every ambition deserves its own team.

A promising idea needs to survive more than one way of looking at the world. Build the room around the decision.

  • Product Owner

    What is the smallest thing we can build that solves a problem worth solving?

    In the recorded example
  • Lead Developer

    What will it take to make this real, and which constraint could break the plan?

    In the recorded example
  • Marketing Manager

    Who needs this, how do we reach them, and what evidence says they will pay?

    In the recorded example
  • Logistics Expert

    Can we deliver reliably, and where does the supply chain become fragile?

    Example seat
  • Finance Director

    What can we afford to commit, and which assumptions determine the return?

    Example seat
  • You, the CEO

    Given the tradeoffs, what are we willing to commit to?

    Always at the head of the table

Choose the size, roles and models of your advisory team

Vision · not yet scheduled

The recorded example seats three advisers. The product direction is a team you size and staff yourself.

The story

A launch that found its focus

A Product Owner, a Lead Developer and a Marketing Manager examine a SaaS launch. The proposal is exciting. Then one line in the project context changes everything.

Recorded example — scripted fictional fixture. No model calls.

  1. 01 · Proposal v1Product OwnerFictional model A — scripted fixture

    Proposal v1: launch five integrations and self-service billing in four weeks.

  2. 02 · ObjectionLead DeveloperFictional model B — scripted fixture

    Two engineers cannot credibly deliver that scope in four weeks. Start with one integration and a supervised pilot.

    context.md · line 4

    Team: two engineers; four weeks available for the launch.

  3. 03 · ObjectionMarketing ManagerFictional model C — scripted fixture

    The acquisition channel is unvalidated. Invite five design partners before funding a public launch.

    context.md · line 6

    Evidence gap: no paid acquisition channel has been validated.

  4. 04 · Revision v2Product OwnerFictional model A — scripted fixture

    Proposal v2: one integration, supervised onboarding, and five design partners. Defer self-service billing and the public launch.

  5. 05 · Final viewsMarketing ManagerFictional model C — scripted fixture

    Final views on v2: Product Owner APPROVED; Lead Developer APPROVED; Marketing Manager INSUFFICIENT_EVIDENCE. Willingness to pay remains untested. Human decision: pending.

How the proposal changed

Proposal v1

Launch five integrations and self-service billing in four weeks.

Changed by the staffing objection · context.md line 4

Proposal v2

One integration, supervised onboarding, and five design partners. Defer self-service billing and the public launch.

Final views on proposal v2

  • Product OwnerApproved
  • Lead DeveloperApproved
  • Marketing ManagerInsufficient evidence
Still open

Willingness to pay remains untested.

Human decisionPending

Two approvals do not erase the uncertainty. Adviser views never decide for you.

The record

Leave with a decision you can explain

Every meeting ends with a new plan and a decision memo: what to do next, why the proposal changed, which evidence mattered and where disagreement remains.

plan.md

# Launch Ledger — plan v2

Recorded example — scripted fictional fixture. No model calls.

Run a four-week supervised pilot with one integration and five design partners. Defer self-service billing and public launch.

The staffing objection changed the scope (context.md, line 4). Validate willingness to pay before expanding.

## Saved evidence

Source: context.md, revision 1. SHA-256: 88a28e448d9deacf8340dcf1b2b38a52be1c9178f158c2c40400451ec5f0b8e9.

Staffing objection: line 4. Acquisition uncertainty: line 6.

Recorded example — scripted fixture. Human decision: pending.

memo.md

# Decision memo

Recorded example — scripted fictional fixture. No model calls.

Proposal v1: five integrations and self-service billing in four weeks.

Proposal v2: one integration and a supervised pilot after the staffing objection (context.md, line 4).

Product Owner: APPROVED on v2.

Lead Developer: APPROVED on v2.

Marketing Manager: INSUFFICIENT_EVIDENCE on v2; willingness to pay remains untested (context.md, line 6).

Human decision: pending. Adviser views do not decide for the human.

## Saved evidence

Source: context.md, revision 1. SHA-256: 88a28e448d9deacf8340dcf1b2b38a52be1c9178f158c2c40400451ec5f0b8e9.

Staffing objection: line 4. Acquisition uncertainty: line 6.

Recorded example — scripted fixture. Human decision: pending.

Retained export from the packaged CLI. Source context.md, revision 1 — SHA-256 88a28e448d9deacf8340dcf1b2b38a52be1c9178f158c2c40400451ec5f0b8e9. View the files

Principles

What a seat at the table requires

  1. 01

    Disagreement earns its place.

    An objection that survives the discussion belongs in the final memo. Consensus is never required to end a meeting.

  2. 02

    Evidence stays inspectable.

    Claims lead back to the exact source version behind them. Missing evidence remains visible.

  3. 03

    Human judgment has the final word.

    You set the direction and make the call. Adviser confidence cannot overrule you.

  4. 04

    Access is yours to grant.

    Local project memory, explicit permissions, preserved originals and deliberate spending limits are part of the design.

Your data

What stays on your machine

Boardroom is a local application. You decide what it reads, and every new file goes somewhere new.

On your machine

  • Projects and the sources you explicitly authorize
  • Exact source snapshots, identified by SHA-256
  • Playback history and export receipts
  • New plans and decision memos, never overwriting originals

Citations resolve to the exact saved revision of a text, PDF or DOCX source

Available

Sent to the providers you choose

  • Selected text and phase inputs, after explicit live-call authorization
  • Through the model accounts you configure, at their pricing

Live workflow implemented for three distinct models from two providers; real-account qualification pending

Preview

Never

  • A Boardroom account or hosted Boardroom service
  • Telemetry from the application

No BOARDROOM account, hosted backend or cloud telemetry

Available

Engineering

Built like infrastructure

A decision tool has to be trustworthy before it is clever. Each statement below links to the evidence behind it.

Application tests
143deterministic integration and end-to-end tests, run on every change
Qualified platforms
3Windows x64, Linux x64, macOS arm64, each installed without Node in CI
The terminal renders results; the application service owns state. Architecture and tradeoffs · Qualification evidence

How Boardroom is built, decision by decision

Roadmap

Where Boardroom stands

Nine plans, each with its own acceptance gate. Progress is reported only once it is proven. See the full roadmap.

  1. Plan 01

    Installable local journey

    Install, explore the recorded example, inspect sources and export a plan.

    Accepted with reservationsRead the reservations
  2. Plan 02

    First real decision

    Live workflow implemented; acceptance still requires the real three-model, two-provider campaign.

    Next
  3. Plan 03

    Human participation

    Intervene, change the context, pause and ask for a conclusion.

    Planned
  4. Plan 04

    Recovery and incidents

    Resume interrupted meetings without replaying completed actions.

    Planned
  5. Plan 05

    Knowledge and memory

    Work on your documents and reuse retained decisions.

    Planned
  6. Plan 06

    Protected investigations

    Grant narrow research and actions with originals preserved.

    Planned
  7. Plan 07

    First use and connections

    Go from the example to your own models without help.

    Planned
  8. Plan 08

    Optional observability

    Diagnose latency, usage and incidents locally or in your own Langfuse.

    Planned
  9. Plan 09

    Public beta

    A reproducible, documented release for Windows, macOS and Linux.

    Planned

FAQ

Questions worth asking

Short answers, with what is available today kept apart from what is planned.

Is Boardroom free?

The recorded example costs nothing and needs no account. Boardroom itself has no account, subscription or payment. Live meetings use your own model provider accounts, billed by those providers.

Is it open source?

Yes. The source is public on GitHub under the Apache License 2.0: use it, modify it and build on it, with the license and notice kept.

Open source under the Apache License 2.0

Available
Can I download it?

Not as a published release yet. You can build it from source today; the project's CI produces a packaged candidate for each qualified platform.

Do I need an API key?

Not for the recorded example. The live preview uses the model keys you supply. Official ChatGPT and Claude subscription routes are being studied and will be announced only once tested end to end.

Live workflow implemented for three distinct models from two providers; real-account qualification pending

Preview
What leaves my machine?

Recorded playback makes no model or cloud calls, and the application sends no telemetry. Authorized live phases send selected context and phase inputs to the providers you configure. Real-account qualification is pending. Read how your data is handled · Try the live workflow.

Why a terminal?

Boardroom is terminal-first for builders: it runs locally, scripts cleanly with --json and keeps the focus on the argument. A graphical interface is possible future work, not a commitment of this version.

Bring the question that matters.

Start with a fictional launch, follow the objection, and inspect the resulting plan.

Explore the recorded exampleFollow the project on GitHub