KC joined as our alpha tester and immediately started treating the system like a live financial operation — not a QA exercise. She wasn’t looking for bugs. She was trying to run a business. The gaps that surfaced weren’t failures of individual features. They were architectural assumptions we’d made about how a CFO thinks that didn’t survive contact with how a CFO actually thinks.
Alpha testing for enterprise software is usually a controlled process. You identify a set of features to validate, you write test scripts, you recruit users who understand they’re testing an unfinished product, and you collect structured feedback against the test plan. This is a legitimate approach that catches real problems before they reach production.
It’s also a fundamentally different activity from what KC did with Nue, which was to sit down in a CFO role and try to actually use it.
The difference between a test and an operation
A tester looking for bugs approaches the system instrumentally: click this, enter that, verify the output matches the expectation. The feedback is “this didn’t work” or “this produced the wrong result.” Useful, specific, and limited to what the test script thought to include.
A CFO approaching the system operationally asks a different set of questions: what does my AR position look like right now? How does this invoice tie back to the contract? Why does this account balance look different from what I’d expect based on last month’s entries? Can I see the open AP aging by due date? The questions aren’t scripted — they’re the questions a financial operator actually has while trying to understand the state of a business.
KC was operating in a CFO-equivalent capacity. She had a real company loaded in the system — thousands of invoices, hundreds of vendor bills, multi-entity structure, live chart of accounts. She was trying to work with it the way she’d work with any financial system she’d inherited.
What she found that we hadn’t anticipated
The gaps she surfaced weren’t in the features we’d thought most about. They were in the transitions between features — the places where the system assumed a certain mental model that a working CFO doesn’t actually use.
The most instructive was around how she navigated between the AR aging and the underlying transactions. Our design had the aging as a summary view and the invoices as a separate module. Her operating instinct was to click from the aging line directly into the invoice, then from the invoice back into the journal entries that captured it in the ledger, then back out to the customer-level view. She expected the financial data to be navigable in the same way she’d navigate a financial model — following the thread from summary to detail to source, in any direction, without losing context.
That navigation model required rethinking how the views connected to each other, not just whether each view individually worked correctly. The test scripts would never have caught it, because the test scripts tested individual views, not the paths between them.
The CFO mental model
What KC’s operating style revealed was a specific mental model that experienced financial operators carry: everything traces. Every number has a source. The AR balance traces to the open invoices; the invoices trace to the journal entries; the journal entries trace to the business event that created them. A CFO who trusts a financial system trusts it because they can follow any number to its origin and the origin is clean.
This means the UI can’t be designed around module boundaries. It has to be designed around data lineage — the natural chain from summarized financial facts back to the transactions that create them, and from those transactions to the business events that drove them. The module boundaries exist in the architecture, but they shouldn’t be visible to someone who’s trying to understand what a number means.
The principle that came out of it
The most useful thing KC’s approach produced was a principle: every number in the system should be traceable to its source without leaving the screen where you found it. Not in a separate audit log. Not in a different module. From the number itself, by clicking through.
This principle has shaped every subsequent UI decision. When a dashboard shows a revenue number, you can click it and see the underlying transactions. When an AR aging shows a balance, you can click through to the invoice, and from the invoice to the journal entry, and from the journal entry to the contract that generated it. The financial data is navigable all the way down, in the same mental model that an experienced financial operator uses to verify that what they’re looking at is real.
KC continues operating against the system in an ongoing alpha capacity. Her questions shape the product more reliably than any test script could.