The Operator Who Builds: Why Finance and Software Should Not Be Strangers

Two crafts that rarely meet

There is a standard way software gets built for a finance office, and it fails in a standard way. The person who runs the process writes down what they think they need. A developer or a vendor reads the document, builds what it says, and delivers a tool that answers a question nobody was asking. Everyone did their job. The failure was structural: the person who understood the problem and the person who built the solution were never in the same head.

Most finance people do not build, and most builders do not know the finance back office. I do both. I spent about ten years running finance and operations in higher education, including a budget north of $30 million, and for much of that time I was also the person writing the tools my own team used. That combination can sound like a personality quirk. I think it is the whole differentiator, because when the operator and the builder are the same person, three specific failure modes disappear.

Failure mode one: requirements lost in translation

A requirements document is a lossy compression of how work happens. The operator writes "the system should route invoices for approval" and leaves out the forty exceptions they handle on instinct, not because they are hiding anything, but because they no longer notice the exceptions. Ten years in, the workarounds feel like the work. The builder, reading the document cold, implements exactly what is on the page, and the gap ships as a defect no one can name.

When the builder has personally done the month-end close they are automating, there is no document to compress and nothing to lose in translation. I do not have to interview myself about where the close stalls. I already know which accrual has to be estimated before the statement posts, which reconciliation only matters in a month where the balance moved, and which report exists because a leader asked for it once and nobody ever checked whether they still read it. The specification is not written down. It is remembered in the hands.

Failure mode two: optimizing the wrong thing

A dashboard built by someone who has never answered for a budget optimizes for what is easy to chart. It shows totals because totals are available and trends because trends look impressive, and it dodges the one number that would make its owner uncomfortable.

A dashboard built by someone who has sat in the budget meeting optimizes for the question that is coming. When I built Tableau dashboards for the operation I ran, leadership checked them weekly, and not because they were decorative. Each view existed to answer a question I had personally been asked across a conference table: where are we against plan, which units are trending over, what changed since last month and why. I knew those were the right questions because for years they had been my questions, asked of me, with my name attached to the answer. That is a design input no discovery interview can substitute for. Answering to a budget teaches you what a report is there to do, and that lesson does not transfer through a survey.

Failure mode three: the handoff cliff

Most internal tools do not die from bugs. They die at the handoff. The consultant finishes the engagement, the developer changes teams, and the tool freezes at the moment of delivery. Six months later the process has changed, the tool has not, and everyone routes around it, usually back into a spreadsheet.

I watched the other version of this play out. At a research center, I built an approval-workflow application to replace a spreadsheet people kept forgetting to update. The spreadsheet did not fail for technical reasons. It failed for a human one: it depended on busy people remembering an administrative chore, and busy people do not. The application outlived the spreadsheet because the person who ran the process also maintained the code. When a policy changed, the tool changed the same week. No ticket queue, no scoping call, no cliff. The operator maintains what the operator built, and maintenance is where internal tools live or die.

The same habit, pointed outward

That habit did not retire when I moved on from the back office. PoP Radar, a public-data product I built, is live today, watching federal contract data nightly. It started the way every good internal tool starts: with a question an operator would ask each morning (what changed since yesterday?) and the smallest piece of software that answers it on schedule without being reminded. The domain is different. The method is identical, and the method is the point.

What AI changes, and what it does not

For most of my career, the building half of this combination was the expensive half. Learning to ship working software while holding down a finance job was a slow, nights-and-weekends proposition, which is why so few operators did it. AI coding tools have collapsed that cost. A workflow application that once took a contractor a quarter to deliver is now within reach of one persistent operator in a couple of weeks.

That means the scarce half has flipped. The hard part is no longer writing the code. It is knowing what to build: which spreadsheet is quietly load-bearing, which approval step exists because of an incident three years ago, which report nobody has opened since its requester left. That is operations knowledge, and it does not come from a prompt. It comes from having run the process, missed the deadline, and answered for the variance. The operators who pick up these tools are going to be very hard to compete with, because the half they bring cannot be downloaded.

An honest limit

I am not a career software engineer, and that is the point. I am not the person to build your trading platform or your database engine, and I will say so out loud. But the software a finance office needs is almost never a hard computer science problem. It is a hard understanding problem: what does this process do, who touches it, what breaks on the 3rd of the month when the statement is late. Ten years of running the process is the qualification that matters there, and it is the one most software teams cannot buy.

If there is a tool in your office that everyone routes around, or a spreadsheet everyone depends on and nobody trusts, the gap is probably not technical. Finding it is what the Financial Operations Assessment is built for: it starts from how the work happens, because that is where the tools should start too.