Case study
A finance platform in five days
A company at the stage where the finance function does not exist yet and a raise is a few months out. What I designed, how each part works, and what the live copy shows.
A fictional company. The figures are illustrative; the system is real.
The situation
The company sells expert data to AI labs. It buys expert time and documents, turns them into training and evaluation data, and bills a handful of labs that pay slowly while the experts are paid weekly. Revenue grew faster than the finance function. The books were not yet on an accrual basis by revenue line, the forecast lived in a spreadsheet nobody certified, and a board meeting and a raise were a few months away.
The founders needed three things by the board meeting. A plan they could defend line by line. Numbers an investor could tie to the ledger. A way to see the business every Monday without asking anyone.
What I designed
One model certifies the plan. The company's data lands once in a locked store. A hub serves the same numbers to people and to agents, each figure with its version and its hash. Four parts, left to right.
How each part works
The operating model
A line-item build: revenue by customer and program, expert pay, documents bought and licensed, headcount by role, opex by line, cash and tax. Five cases sit side by side. Every judgment is a typed input with a label, a unit and a source note, and the checks tab reads all pass in every case before the export runs.
The export and the hash
Certification writes the export: values only, one file per view, and a manifest with a hash for each. The import checks every hash before a file enters the page, and the page checks them again at load. A mismatch shows no number at all.
The page
Phone first. Today shows six numbers, cash, the triggers and four paths. Every tile carries its own case, grain and period. A tap opens a drawer with the figure, its trend, the lines behind it, the inputs behind it for that case, and the decision that reads it. Cash, orders, delivery and the data partner each run from a card through a stored run to a decision tile and a recommendation.
The question box
Plain questions, answered from defined metrics only. The test set holds forty scored questions and ten held out, each with the figure it must quote or the refusal it must give. Every answer is logged with the model version.
The MCP server
Eight read-only tools for the team's agents, under four roles: owner, analyst, reviewer and agent. Every call is logged before it is answered. No log, no answer.
The Monday flash
The same six numbers by email and push every Monday, from the same export.
The accelerated close
November closed in ten business days, the year-end in five, January in three, then continuous from February. The 90-day plan sits on the system design page.
How it was built
Five days from a one-hour conversation. I designed the system and set the standards. Claude Code and Codex wrote the code under those standards, one writer per file. A certification gate decides whether a model version ships: the format and structure audits, the formula and convention lints, the key-by-row diff against the version's brief, and the export's period ties. A test suite of close to five hundred checks runs against the page: periods, paths, charts, the question box's test set, and the MCP server's doors and roles.
What the live copy shows, and what it leaves out
The live copy is the same page on a fictional company, Halden Labs. Every input was re-cut, and the numbers were regenerated and certified through the same chain. It has no login, so the roles and the visit log are off. The question box shows its scored test set rather than a live model call. The MCP server is documented from its code rather than served. The Monday flash is one sample.
The workbook is not for download. Ask me for it.