They built software for a queue.
We built it for a table.

The cube

Every incumbent CFP tool puts a reviewer in solitary confinement. You log in, the queue serves you a submission, you score it alone, you never see what anyone else thought. The queue is tireless, the work is thankless, the numbing is the design. Committees go delinquent. Chairs spend their evenings writing nag emails to people who were excited about reviewing six weeks ago.

One of us literally wrote his own app against Sessionize's API just to escape the queue — to shop for the submissions that actually fascinated him instead of processing whatever the tool felt like surfacing next.

When your reviewers are writing software to route around your review tool, the tool is the problem.

The table

Picture a group of people who love the field, gathered around a shared table, reading submissions together. They argue. They get dazzled by what people are building out there. They learn from each other's taste — the person next to you has a completely different instinct about what makes a great talk, and you need that.

Every submission is on the table. Every score is signed. Every comment is part of a conversation, not a note dropped into a void.

You can't wait to open the next one — because it might be the talk of the year, and you get to be the person who finds it.

What we built

• Every reviewer sees everything — no queue, no assigned pile, no blind spot.
• Every rating is signed. Scores have names. You know whose 4.5 that is.
• Comments are a conversation. They thread, they accumulate, they're archived.
• Committees are lenses that focus your view — not walls that confine it. A committee scopes what you see and how coverage math is measured. It never locks anyone out.

Configurations are settings, not remodels

Blind review? A toggle. Speaker identity is hidden from you on the proposal until you have voted — then revealed. No ceremony, no re-configuration, one checkbox.

Tracks? Committees scope the view and the coverage math without gating who may look. You can have a committee per track, a committee per day, or one committee for the whole thing. None of those choices remakes the product.

What we refuse to build

Formal review rounds. Trusted reviewers do not need Round 1 → Round 2 machinery to read, rate, and discuss submissions. Put every proposal on the shared table and let the committee do its work.

Rich Hickey famously said that no one has ever said, ‘I love filling out forms. I love filling out lots of fields.’ That is the antithesis of what we want to build.

I have reviewed thousands of submissions for my own conferences and many others. My conclusion is that you never need more than Stars and comments.

• One score, many reasons.
• Stars expresses preference; comments preserve why.
• No weights, formulas, configurable Numeric/Dropdown/Free-text scorecards, or workflow-driven review rounds.
• Committees converge through conversation and progressively narrowing the pool, not form completion and scorecard arithmetic.
• Quick Rate is the canonical review surface.

Everything else we refuse, and why

Thirty teams built this product at the same time we did. Here is every feature we decided not to build, the reason, and how many of those thirty shipped it anyway. An absence with no reason attached reads as a gap; an absence with its reason attached is a position.

• Multi-round review with per-round reviewer pools, assignment caps, and auto-distribution — built by 28 of 30. Review is a conversation among trusted peers over a shared table. Rounds and assignment bureaucracy are the incumbent's org chart, not a program committee's work. The board's two default sorts are the work queues, per-member track scope is our assignment model, and a CONTESTED sort is our answer to "advance a round."
• Weighted multi-criterion scorecards with per-criterion normalization — built by about 26 of 30. It converts a conversation into a spreadsheet and manufactures a false precision that then has to be explained. One score, many reasons. Extra criteria exist as data — feature-flagged, API-exposed, no reporting layer. We refuse the reporting layer, not merely the absence of it.
• Blind review as a global mode with per-round anonymity settings — built by about 20 of 30. A matrix of per-round toggles is not a policy; it is a thing nobody can reason about at 11pm the night before decisions. Blind review is one visible, explainable policy control with a live reveal. Refuse the matrix; keep the switch.
• Sponsor and exhibitor CRM — tiers, contacts, benefits, inventory, contracting — built by 1 of 30 deeply. It is a different business (sales) attached to a different object (money), and sponsor tiers drag in exactly the permission fortress we refuse: a committee is a roster plus a scope filter, never a fortress. A sponsored session is a session; we do not sell sponsorships. A flag on a session. That is the whole feature.
• An attendee social graph — friend requests, per-field contact consent, cross-event follows — built by 1 of 30. It makes us the custodian of attendee-to-attendee PII and consent state, for a feature no organizer asked for in the ethnographic study. Personal itineraries are the attendee value we do want. The social layer is not.
• Auto-sending deadline and due-date reminders on a timer — built by about 10 of 30. Writing to the outside world as the organizer requires a per-artifact human yes. A timer that mails your speakers is a robot signing your name. The system computes the chase list and pre-selects the recipients; a human clicks send. This costs us a rubric point on purpose.
• A second, AI-specific write path — built by nobody deliberately; several drifted toward it. An AI verb that is not an existing domain verb is a second source of truth wearing a new hat. Every surface — UI, API, MCP, agent — goes through one authorized command registry. If an agent can do it, a person could already do it: the same command, appending the same fact through store/append!. A write path not expressible that way is refused.
• Client-side optimistic schedule state that mirrors server conflict rules — built by 5 of 30. It is a second source of truth the server cannot see. Every team that shipped it now maintains its conflict logic twice, and the two copies disagree the first time one of them changes. Our scheduler has exactly one implementation of every rule.

Twenty-nine of thirty teams built history as an afterthought

Every one of them stored the current state in a row and overwrote it, then bolted on a bespoke history table and a best-effort audit log. We did not have to argue for event sourcing. Thirty independent teams argued for it against themselves, in their own code comments:

• One team's own code comment admits a partial failure can show "accepted" on the board with no decision record — healed later by a retry, if the retry comes.
• Another's audit.go:29 admits the workspace can commit while the audit append fails.
• A third's activity writer explicitly swallows logging failures.
• A fourth's reject path deletes sessions in browser state but not in the system of record, so a reload resurrects stale scheduling.
• A fifth calls its publications immutable while republish runs an UPDATE on a single row keyed by event id.
• A sixth's own lifecycle trace has to print "approved, but no content version records who approved it."

Every fact in Curtain Call is appended, never overwritten. Who decided, when, and what the page looked like on Tuesday are not features we added — they are what the store is.

We're done with box-and-wire tools

We're sick and tired of box-and-wire tools like WooCommerce and Ontraport that just create nightmares — a thousand dropdowns and flowchart nodes to express something you could write in a sentence.

Instead: beautiful configuration-as-data that your LLM can write for you. Your workflow, your way — without the stupid box-and-wire GUI stuff.

Your entire conference process is one readable, testable, forkable config document. Fork it, version it, hand it to the next chair. It's not a settings page — it's a spec.

Agent-operable by design

Point your own LLM at our API — have it help your committee find the reviews that need eyes, chase coverage gaps, draft your speaker letters.

The product exposes the same API the UI uses. There is no secret backstage. The API is a first-class citizen, documented, versioned, and open.

Curtain Call is the spiritual successor to BusyConf — the tool that conference organizers actually loved, until Heroku repricing ended it in 2023. We ran our own events on BusyConf for five years. We know what it felt like to lose it. This is what we wish we'd had the whole time.

See the live product — create your event →