Override

A working model of a Broadway deal—capitalization, waterfall, scenarios and investor outcomes in one place.

View Live ProductView on GitHub
Topics
AI · Finance · Theater
Format
Financial operating system
Focus
Capitalization, ownership, and investor workflows
Status
SHIPPED
Override product screenshot
StackNext.js · TypeScript · Tailwind · Firebase · Recharts · Vitest

Why this exists

I wanted to know how far I could get building with an AI coding tool. Rather than make a toy, I picked a real problem that annoyed me in a domain I wanted to understand better.

Broadway investing supplied both. The first position I tracked arrived as three documents: a term sheet PDF, a cap-table spreadsheet, a subscription agreement by email. Three months later the cap table and the term sheet disagreed. Nobody had done anything wrong—each document was accurate the day it was written, and a production being capitalized changes constantly. So I did what everyone does: opened the spreadsheet, rebuilt the waterfall by hand, and worked out what my position now meant. Spreadsheet archaeology.

Three things were wrong with that, and they are different problems. The work was manual—ownership, recoupment and investor outcomes recalculated by hand every time anything moved. The deal was hard to understand, its economics spread across documents that took domain knowledge to interpret. And it was static: every artifact described one state of the deal, so I could read what the producers expected to happen and had no way to ask what happened to my position if they were wrong.

Products like Carta had shown me what the alternative looks like—complicated ownership structures made legible and interactive by software. Broadway financing has all the same ingredients: ownership, capitalization, waterfalls, returns. I hadn’t encountered anything like that from the investor’s side. So the question became: what would this experience be like if the deal itself were software?

Override is that question, built. It is also the substrate for a second one—whether I could learn an unfamiliar, specialised domain deeply enough to build credible software for it, and how much of that an AI workflow could carry. The two ran together: I learned the domain by trying to model it, and learned the tooling by trying to ship it.

I named it after a line in the waterfall. The override, as I learned the word, is the producer’s percentage taken off the top—the share that comes out before investors see a distribution. Opaque outside the industry, immediately legible to any producer who has negotiated one.

How it works

Structure the deal. A producer sets the capitalization and unit price, the weekly operating nut, the house terms, eleven royalty participants and the waterfall structure. First-time users can walk it as a guided stepper; experienced ones get every section at once, which is the default. The producer and the prospective investor are both first-class here—the dashboard’s primary control is a My Productions / My Investments toggle, because I built this from the side of the table that only ever sees the second view.

Model the outcome. Broadway money moves in a fixed order, and the order is the product. Gross box office less credit-card fees and the house’s cut gives adjusted gross; eleven royalty participants take their share; then the weekly nut, then the general partner’s fee. What survives is operating profit, and only then does the waterfall run. Two structures ship. Under recoup-first, investors are repaid in full before anyone shares profit, and in the week the show crosses its capitalization the engine splits that week’s profit at the crossing point rather than treating the whole week as one side of the line. Under share-from-dollar-one, profit sharing runs alongside recoupment from the first performance. Around both sit per-investor returns, an approximate IRR, breakeven occupancy, and a sensitivity grid that re-runs the model across a matrix of occupancy rates and run lengths.

The weekly cascade as an investor sees it, computed by the same engine the producer's own model runs: gross box office down through credit-card fees and the house, royalties and the weekly nut to operating profit, then the GP's management fee, then what reaches investor recoupment.
Figure 1: The weekly cascade as an investor sees it, computed by the same engine the producer's own model runs: gross box office down through credit-card fees and the house, royalties and the weekly nut to operating profit, then the GP's management fee, then what reaches investor recoupment.

Share the deal. The producer generates a link and sends it. There is no account to create, no invitation to accept, and no portal to log into—the prospective investor opens a URL and reads the deal. What they get is a snapshot taken at the moment it was shared, not a live feed of a model the producer is still editing.

What a prospective investor gets on opening a deal-room link, with no account: three cases side by side, each with its assumptions above its outcome. Bear and Base never recoup, so investor distributions are zero; Bull recoups in week 20 and returns $3.4M. Demonstration figures—the room's own producer note calls every number a placeholder.
Figure 2: What a prospective investor gets on opening a deal-room link, with no account: three cases side by side, each with its assumptions above its outcome. Bear and Base never recoup, so investor distributions are zero; Bull recoups in week 20 and returns $3.4M. Demonstration figures—the room's own producer note calls every number a placeholder.
  • 6 daysscaffold to the whole-app commit
  • Investor's seatthe only domain access
  • 1 deal roomin production, a demonstration

Decisions that shaped Override

These are not calls I arrived with. They are the ones that emerged as I understood Broadway finance well enough to have an opinion about it, and as I found out what an AI workflow could and could not carry. Each names what I ran into, what I did about it, and what it cost—because a decision that cost nothing was not a decision.

  1. MethodValidated

    Build for a real niche, not an AI demo

    What I encountered
    I wanted to know what AI coding tools could actually do, and every tutorial and toy app I could find had removed the hard parts—no unfamiliar domain rules, no ambiguity, no changing requirements, nothing to get wrong.
    What I decided
    Use a real problem I did not fully understand, in a domain I wanted to learn, and treat the domain research as part of the build rather than a prerequisite to it.
    Why
    A demo only exercises code generation. A domain I had to learn forced the workflow through the parts that are actually hard: deciding what the abstractions are, discovering a rule I had encoded wrongly, and changing my mind about the product halfway through.
    Cost
    I was learning the domain and the tooling at the same time, which means some of what shipped encodes my early understanding of Broadway finance rather than my current one. The engine has not been revisited since the product window closed.
    What it changed
    Domain research became part of the development loop rather than a phase before it. The agent brief and the application arrived in the same commit, with Broadway benchmarks and their industry sources encoded into the instructions from the first day.
  2. ComprehensionMixed

    Model the deal, don't digitize the paperwork

    What I encountered
    The terms of my own investment were technically available to me. Understanding how they affected my position meant knowing what to look for across a term sheet, a cap table and a subscription agreement, and how the pieces related.
    Over
    A better-organised document. Searchable PDFs, a cleaner investor portal, the deck as a web page—the obvious answer, and the one that leaves the reader doing the same work with better typography.
    What I decided
    Represent the deal as structured data and calculated outcomes—capitalization, waterfall mechanics, royalty participants and per-investor returns as connected parts of one model.
    Why
    Making a document easier to browse does not make the economics easier to understand. The question is not where a term is written down; it is what that term does to the number at the bottom.
    Cost
    Override cannot represent a bespoke waterfall provision. Broadway deals carry one-off terms constantly, and anything the model does not have a field for has to be approximated or left out—which is the moment a producer goes back to the spreadsheet.
    What it changed
    Terms, capitalization, waterfall mechanics and investor outcomes did become parts of one model rather than four documents, and the same engine computes the producer's view and the investor's. What has not been tested is whether a producer agrees the abstractions are the right ones.
  3. ExplorabilityMixed

    Make the numbers playable

    What I encountered
    The investment materials could tell me what the producers expected to happen. They could not tell me what happened to my position if the show ran at a lower occupancy, or for twelve fewer weeks, and there was no way to ask.
    Over
    A single projected outcome, which is what a term sheet and most investor decks already show, and what a producer is usually asked to supply.
    What I decided
    Make scenario modeling a core surface rather than an output: Bear, Base and Bull side by side, each with editable occupancy, ticket price and run length, re-running as you type, plus a sensitivity grid across occupancy and run length.
    Why
    The interesting question was never what the deal projects. It was what happens when an assumption changes. A single number invites a belief it has not earned; a range you can move is something you can interrogate.
    Cost
    Three cases is a frame the producer cannot leave. The array is fixed at Bear, Base and Bull with no add and no remove, so a producer who models a dozen cases has to collapse them into three.
    What it changed
    Override became an interactive model rather than a better way to present a deal. The three-case frame kept that exploration legible, at the cost of flexibility for producers who model many more.
  4. ScopePending

    Build a product, not a SaaS business

    What I encountered
    Everything a real SaaS needs—billing, onboarding, a CRM, account administration, an acquisition funnel—was available to build, and none of it was what I wanted to find out.
    What I decided
    Optimise for the product problem and the domain, and leave the company-shaped work unbuilt. There is no billing, no team accounts, no lead pipeline, and the investor-facing surface deliberately has no accounts at all.
    Why
    The question I was testing was whether I could learn a specialised domain well enough to build credible software for it—not whether I could sell subscriptions to Broadway producers. Building the funnel would have consumed the time the domain needed and answered a question I was not asking.
    Cost
    There is no distribution, so there is no feedback loop. Nothing about this build tells me whether producers would pay, adopt, or even finish onboarding—and the roadmap items that would matter to a business, the lead CRM and the signing workflow, are exactly the ones that stayed unbuilt.
    Validation boundary
    Not yet validated, and by construction it cannot be from here. What resolves it is a producer running a real capitalization in it—which is also the only thing that would tell me whether the domain modeling was right.
Translating a contract clause into something you can see: post-recoup profit split per hundred dollars, with the GP's carve coming out of the investor pool rather than the creative pool—forty-five cents to the limited partners, five to the GP, fifty to creatives. The callout is the model declining to flatter the deal, because this demonstration never recoups.
Figure 3: Translating a contract clause into something you can see: post-recoup profit split per hundred dollars, with the GP's carve coming out of the investor pool rather than the creative pool—forty-five cents to the limited partners, five to the GP, fifty to creatives. The callout is the model declining to flatter the deal, because this demonstration never recoups.

Building for financial trust

Financial software needs a higher standard than “the tests pass,” and what actually stands behind the arithmetic here is a calibration rather than a suite. The engine’s documentation carries a check built from Hadestown’s published economics—947 seats, 93% occupancy, a $155 average ticket, a $530K weekly nut, 14% royalties—together with what the model should return. I re-ran it against the shipped engine while writing this page, six months after it was written and with nothing in CI holding it in place. It reproduces exactly: $1,046,283 weekly gross, 57.0% breakeven, recoupment in week 37.

The test suite is less reassuring than its green tick suggests. Eighty-six tests pass, but only eight touch the engine and every one enters through the same file, so the weekly pipeline, the phase function and the ownership rollup have no direct test at all. Two assertions check money against the inputs, both of them pool percentages; the ones that look like proof check the engine against its own output.

Which is roughly how a real flaw survived. A producer’s screen shows which phase the waterfall is in, and the obvious source is the profit-sharing toggle they just clicked. The phase function reads the deal’s post-recoup investor split instead, so the badge reports the economic condition rather than a flag that can be set independently of it—the right instinct, incompletely applied. The distribution math one file over still consults the toggle, so turn the toggle off without changing the split and the badge reads “Profit Sharing Active” while the engine pays investors nothing, and the deal room shows a prospective backer a 50% investor pool for that same deal. The repository records it as a known inconsistency and says to preserve the behaviour. Two sources of truth for one economic question is exactly the failure a financial tool cannot afford.

What does hold is structural. The financial engine is five files with no React and no Firebase import in any of them, sealed off from both the interface and the database—a producer configures the rates and the splits, and the engine fixes the order the money moves in. But that boundary exists by convention, not enforcement. No lint rule, no import restriction, no CI check polices it; it holds because the rules files say so and reviewers read them.

Most of the code is agent-written, and the whole application arrived in a single commit six days after the scaffold. The gap worth naming is the kind an agent does not catch: the repo’s rules name the three engine files as its highest-risk zone, while the automated review gate watches auth and payments directories that do not exist in this repository. Which is the same failure twice, one level apart—Override knew the financial rule and did not enforce a single source of truth for it; the agent workflow knew where the risky code lived and did not enforce review there. The judgment lives in prose and the machine gate aims elsewhere.

What I learned

Theatrical financing has its own vocabulary and its own math—recoupment triggers, running royalty offsets, overcall provisions, creative fee waterfalls—and industry professionals understand all of it perfectly well. The tooling around them stayed general-purpose anyway. So the work was never explaining Broadway to Broadway. It was finding the abstractions that make the math accessible without flattening the domain, and building one surface a general partner and a first-time angel investor can both read.

The clearest lesson is that a domain-specific product buys precision by giving up reach, and you have to actually want that trade. A generic waterfall engine would have served film finance and real-estate syndication too. Encoding Broadway’s own rules instead makes the product wrong for every other industry, and right in the small places that decide whether a producer trusts the number or checks it by hand.

What I cannot tell you is whether a producer agrees. Override has never run a real deal: no real capitalization managed in it, no outside investor admitted, no deal-room link sent to a backer, and nothing in the repository or its issue history that suggests otherwise. The only deal room in production is a demonstration built with sample figures.

Override proved the building part. I could use AI tools to learn an unfamiliar domain, encode its rules, and turn a workflow I found frustrating into working software.

It has not proved the market part. A producer running an actual capitalization in it, with real investors reading the deal room, is the test that matters—and the one it has not had.