Override

I built Override to see what AI coding tools could do with a real problem. It connects a Broadway deal's capitalization, waterfall, scenarios, and investor returns in one model.

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. I picked a real problem that annoyed me, in a domain I wanted to understand better.

Broadway investing supplied both: I invested in the Broadway revival of Proof. The first position I tracked arrived as three documents: a term sheet PDF, a cap-table spreadsheet, and a subscription agreement by email. Three months later, the cap table and term sheet disagreed. Nobody had done anything wrong. Each document was accurate the day it was written, and a production changes constantly while it is being capitalized.

So I opened the spreadsheet, rebuilt the waterfall by hand, and worked out what my position now meant. Spreadsheet archaeology.

I had three separate problems. The work was manual: I recalculated ownership, recoupment, and investor outcomes whenever anything moved. The deal was hard to understand: its economics were spread across documents I needed domain knowledge to interpret. It was also static. I could read what the producers expected to happen, but each artifact described one state of the deal. I could not ask what happened to my position if they were wrong.

Products like Carta had shown me an alternative: software could make complicated ownership structures legible and interactive. Broadway financing had the same ingredients: ownership, capitalization, waterfalls, and returns. I hadn’t encountered anything like that from the investor’s side. What would the experience be like if the deal itself were software?

I built Override to answer that question. It also let me test whether I could learn an unfamiliar, specialized domain well enough to build credible software for it, and how much an AI workflow could carry. I learned the domain by trying to model it. I 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, before investors see a distribution. Opaque outside the industry, immediately legible to any producer who has negotiated one.

The technical record below runs through 2026-10-06. The production deal-room count is dated separately to its last read on 2026-08-28.

How it works

Structure the deal. A producer sets capitalization and unit price, the weekly operating nut, house terms, eleven royalty participants, and the waterfall structure. First-time users can use a guided stepper. Experienced users can see every section at once, which is the default. Both the producer and prospective investor have a place in the product. The dashboard’s primary control is a My Productions / My Investments toggle. I built it 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. Credit-card fees and the house’s cut come out of gross box office to give adjusted gross. Eleven royalty participants take their share, then the weekly nut comes out, then the general partner’s fee. What survives is distributable profit. Only then does the waterfall run.

Two structures ship. Under recoup-first, investors are repaid in full before anyone shares profit. In the week the show crosses its capitalization, the engine splits that week’s profit at the crossing point. It does not put the whole week on one side of the line. Under share-from-dollar-one, profit sharing runs alongside recoupment from the first performance.

The same model gives per-investor returns, an approximate IRR, breakeven occupancy, and a sensitivity grid that re-runs across 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. The prospective investor opens the URL and reads the deal, with no account to create, invitation to accept, or portal to log into. The room holds a snapshot taken when it was shared. The producer can keep editing the model without changing what the investor is reading.

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 as of 2026-08-28, a demonstration

Decisions that shaped Override

I did not arrive with these decisions worked out. They emerged as I learned enough Broadway finance to have an opinion about it, and found what an AI workflow could carry. Each records what I ran into, what I chose, and what it cost. 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 do. The tutorials and toy apps I could find had removed the hard parts: unfamiliar domain rules, ambiguity, changing requirements. There was nothing left to get wrong.
    What I decided
    I picked a real problem I did not fully understand, in a domain I wanted to learn. Domain research would happen as I built it.
    Why
    A demo would only exercise code generation. Learning a domain forced me through the harder work: choosing abstractions, discovering I had encoded a rule wrongly, and changing my mind about the product halfway through.
    Cost
    I was learning the domain and the tooling at the same time. Some of what shipped reflects my early understanding of Broadway finance. The engine had not been revisited since the product window closed, as of 2026-10-06.
    What it changed
    The research became part of the development loop. The agent brief and the application arrived in the same commit, with Broadway benchmarks and their industry sources in the instructions from the application's first day.
  2. ComprehensionMixed

    Model the deal, don't digitize the paperwork

    What I encountered
    I had the terms of my investment. To understand what they did to my position, I had to know what to look for in a term sheet, a cap table, and a subscription agreement, then work out how the pieces related.
    Over
    I could have made the documents easier to browse: searchable PDFs, a cleaner investor portal, or the deck as a web page. The reader would still do the same work with better typography.
    What I decided
    I made the deal structured data: capitalization, waterfall mechanics, royalty participants, and per-investor returns connected in one model, with outcomes calculated from those terms.
    Why
    I needed to understand what a term did to the number at the bottom. Knowing where to find it in a document did not answer that question.
    Cost
    Override cannot represent a bespoke waterfall provision. Broadway deals constantly carry one-off terms. If I have no field for a term, it has to be approximated or left out. That is where a producer goes back to the spreadsheet.
    What it changed
    Terms, capitalization, waterfall mechanics, and investor outcomes became parts of one model rather than four documents. The same engine computes the producer's view and the investor's. I have not tested whether a producer agrees I chose the right abstractions.
  3. ExplorabilityMixed

    Make the numbers playable

    What I encountered
    The investment materials told me what the producers expected. I could not ask what happened to my position if occupancy fell or the show ran for twelve fewer weeks.
    Over
    I could have shown one projected outcome, as a term sheet and most investor decks do. That is what a producer is usually asked to supply.
    What I decided
    I put Bear, Base, and Bull side by side, with editable occupancy, ticket price, and run length. The model re-runs as you type. A sensitivity grid lets you explore occupancy and run length together.
    Why
    I wanted to see what happened when an assumption changed. A single number invites a belief it has not earned; a range you can move is something you can interrogate.
    Cost
    The producer cannot leave that three-case frame. Bear, Base, and Bull are fixed: no add and no remove. A producer who models a dozen cases has to collapse them into three.
    What it changed
    Override became an interactive model of the deal. Three cases kept the exploration legible, but left less flexibility for producers who model many more.
  4. ScopePending

    Build a product, not a SaaS business

    What I encountered
    I could have built billing, onboarding, a CRM, account administration, and an acquisition funnel. None would answer the question that brought me here.
    What I decided
    I put my time into the product problem and learning the domain. I left billing, team accounts, and a lead pipeline unbuilt. The investor-facing surface deliberately has no accounts at all.
    Why
    I wanted to know whether I could learn a specialized domain well enough to build credible software for it. Building a subscription funnel would have used the time that work needed and answered a question I had not asked.
    Cost
    I have no distribution and no feedback loop. This build cannot tell me whether producers would pay, adopt it, or finish onboarding. The lead CRM and signing workflow stayed on the roadmap, unbuilt, though both would matter to a business.
    Validation boundary
    I cannot validate this choice from the build alone. I need a producer to run a real capitalization in it. That is also the test that would tell me whether I got the domain modeling 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 dollars to the limited partners, five to the GP, fifty to creatives. The callout is the model declining to flatter the deal, because this demonstration does not recoup at its base-case assumptions.
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 dollars to the limited partners, five to the GP, fifty to creatives. The callout is the model declining to flatter the deal, because this demonstration does not recoup at its base-case assumptions.

Building for financial trust

Financial software needs a higher standard than “the tests pass.” The arithmetic here rests on a calibration. The engine’s documentation uses Hadestown’s published economics: 947 seats, 93% occupancy, a $155 average ticket, a $530K weekly nut, and 14% royalties, along with the results the model should return.

When I wrote the August 2026 version of this page, I re-ran that check against the shipped engine, six months after it had been written. Nothing in CI held it in place. It reproduced exactly: $1,046,283 weekly gross, 57.0% breakeven, recoupment in week 37.

The green test result is less reassuring. As of 2026-10-06, a hundred and nine tests passed, up from eighty-six in August. Only eight touched the engine, all through the same file. The weekly pipeline, phase function, and ownership rollup had no direct test. Two assertions checked money against the inputs, both pool percentages. The assertions that looked like proof checked the engine against its own output.

The gap helps explain how a real flaw survived. The producer’s screen shows which phase the waterfall is in. The obvious source is the profit-sharing toggle the producer just clicked, but the phase function reads the deal’s post-recoup investor split instead. The badge reports an economic condition rather than an independently set flag. That was the right instinct, incompletely applied.

The distribution math one file over still reads the toggle. Turn it off without changing the split, and the badge reads “Profit Sharing Active” while the engine pays investors nothing. The deal room shows a prospective backer a 50% investor pool for that same deal. The repository records the inconsistency and says to preserve the behavior. Two sources of truth for one economic question is exactly the failure a financial tool cannot afford.

One structural boundary does hold. The financial engine is five files with no React or Firebase import, separate from the interface and database. A producer configures rates and splits; the engine fixes the order the money moves in. That separation is held by convention. No lint rule, import restriction, or CI check polices it. The rules files require the separation, and reviewers read them.

The whole application arrived in a single commit titled “Updates via Claude Code,” six days after the scaffold. The repository’s rules name the three engine files as its highest-risk zone. The automated review gate watches auth and payments directories that do not exist in this repository.

I had the same gap at two levels. Override knew the financial rule but did not enforce one source of truth for it. The agent workflow knew where the risky code lived but 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 math: recoupment triggers, running royalty offsets, overcall provisions, and creative fee waterfalls. Industry professionals understand them perfectly well. Their tools stayed general-purpose anyway. I needed to find abstractions that made the math accessible without flattening the domain, in one surface a general partner and a first-time angel investor could both read.

A domain-specific product buys precision by giving up reach. I had to want that trade. A generic waterfall engine could also have served film finance and real-estate syndication. Encoding Broadway’s rules makes Override wrong for those industries, and precise in the small places where a producer decides whether to trust a number or check it by hand.

I cannot tell you whether a producer agrees. As of 2026-10-06, nothing in the repository or its issue history showed Override running a real deal: no real capitalization managed in it, no outside investor admitted, and no deal-room link sent to a backer. That is the scope of the record. As of 2026-08-28, the only deal room in production was 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. It has not had that test.