Why Not Just Build It Yourself With AI?

This is the question. Not "is your product good", not "how do you compare to the incumbent". The question that decides whether a finance tool gets bought in 2026 is: why would I pay you when I can ask Claude to build it?

I ask myself this roughly once a month, and I run a company whose answer had better be good.

So here is the honest version. Not the version where the objection is a misunderstanding to be corrected. The version where the objection is often right, and where it is worth knowing exactly when it stops being right.

The DIY cases are real, and they are getting better

Start by conceding the strong form of the argument, because the weak form is a straw man.

A fractional CFO with no coding background built a multi-entity, multi-currency FP&A application in six weeks. Three linked statements, driver-based scenarios, consolidation, integrations into the usual accounting systems. Running cost: about $160 a month of infrastructure, replacing roughly $8,000 a year of software. He did not write code. He described the logic and let the agent write it.

A finance lead at a scale-up built a revenue recognition portal on Supabase and Vercel instead of buying one. About a month of work and roughly 7 million tokens. Once it was live, the language model left the pipeline entirely: data moves between the source systems and the app with no model in the loop. The AI was used to produce something deterministic, not to run it.

The head of an outsourced-CFO firm wired a read-only connection into his ledger, handed the agent his financial model, his board decks, and the answers to two dozen questions about tacit context, and got back a review of his own books that his co-founder, a CPA of twenty-plus years, took for an auditor's work.

None of these people are being fooled. They are competent, they know what a bad model looks like, and they shipped. Any argument that starts by explaining to them that this cannot work is over before it begins.

And the trend runs the same way at the level of the firm. A 55-person company reported saving in the order of $100,000 a year by rebuilding an internal tool with an agent rather than renegotiating its contract. The figure is the company's own and is not independently verified, but the direction is not in doubt.

Where DIY genuinely wins

There is a clean test for this, and it comes from a practitioner rather than a vendor: would two different people, doing this task by hand, produce the same answer?

If yes, the task is deterministic. Reconciling two files. Reclassifying transactions against a rule set. Reformatting a known export. Build it. An agent will write that script in an afternoon, it will run every month, and paying a subscription for it is a waste of money.

The same source adds the rule that follows from it: if you will not run it three times, do not build it.

That covers a large share of what finance teams actually spend their week on, and it is the honest reason the DIY wave is not a bubble. A great deal of finance work is deterministic, was always deterministic, and was only ever done by hand because writing the script cost more than doing the task. That cost went to nearly zero. The work should move, and it is moving.

Anyone selling into this market who pretends otherwise is asking to be ignored.

The three questions that actually decide it

What the DIY case does not settle is the class of work where the artefact outlives the session. And there, the decision comes down to three questions that the speed of the first build answers none of.

1. Who maintains it in six months?

The app exists. The person who described it into being has moved on to the next thing, or changed firm, or is on the client engagement that pays. A driver changes. A new entity is acquired. The revenue recognition policy shifts.

Now someone has to open a codebase they did not write, that no one else has read, that has no tests beyond the ones the agent volunteered, and change one rule without breaking the other forty. In a software team, this is a solved problem with a name and a whole discipline behind it. In a finance team of four, it is a single point of failure wearing the disguise of a productivity win.

The version of this question that stings: can a second person change the logic without asking the first one? If not, you did not buy independence from a vendor. You bought dependence on a colleague.

2. Which file goes to the committee?

Almost every finance artefact eventually has to leave the building. It goes to a board, a lender, an acquirer, an auditor, a sponsor. And when it does, it is a workbook, because that is what the other side opens.

A self-built application does not solve this. It defers it. At the end you still export, and the question is whether what comes out is a workbook someone can open, trace and challenge, or a dump of values with no formulas behind them.

This is where the benchmarks are worth reading, because they measure the artefact rather than the answer. Columbia Business School's MBABench scores agents on whether they build a workbook to professional standards: clean formulas, readable structure, ready for a managing director to review and edit. Across more than ten frontier models the best score was 69 out of 100, and none would pass as a reliable first-year analyst. The recurring failure mode is the one that matters here: they hardcode values instead of expressing them as formulas. As the team put it, they can do the math but struggle to translate it into the spreadsheet itself.

Wall Street Prep's 2026 comparison found the same shape from a different angle. Every tool tested beat a human on setup time, 15 to 25 minutes against one to two hours. None of them beat a weak analyst on the finished model. Interest that depends on a debt balance which itself depends on the cash flow that interest feeds got resolved with a plug rather than a real link, in every tool tested.

Building the app yourself does not change any of that. The agent that writes your application is the same agent that writes those workbooks, and the hardcode it leaves in row 34 is the failure that passes the eye test whether the surrounding tool was bought or built.

3. What does the tenth client cost?

This is the question that separates a good afternoon from a business.

One model, built once, for one company: DIY is unbeatable. The economics are not close.

Ten clients, each with a different chart of accounts, a different fiscal calendar, a different definition of contribution margin, each needing the same monthly loop of actuals in, forecast out: now the thing you built once has to be reinstantiated ten times. Every time, the structure gets rebuilt from a description rather than reused as an object. Every time, the context gets re-explained.

There is a real workaround here, and it deserves to be named because it works: keep the input format identical every month. Same columns, same structure, no exceptions. Discipline substitutes for structure, and it costs nothing.

It also breaks the first time a source system changes its export, or two systems both claim the word "revenue" and nothing in the process says which one wins. The practitioner who recommends that discipline says so herself: at that point the exercise is not hard, it is impossible.

The cost that building faster does not touch

There is a category error running underneath the whole build-versus-buy conversation, and it is worth naming.

Generation got cheap. Verification did not.

Finance professionals report spending close to 13 hours a week reconstructing, validating and defending AI outputs, according to an IDC survey of 2,275 senior finance decision-makers (IDC for Sage, 2026). The research is vendor-sponsored, which is worth knowing, and the sample is large enough that the order of magnitude holds.

In a survey of 63 senior financial modellers by the Financial Modeling Institute, not one said they would trust an AI-produced model without human review. Half reported little or no time saved.

Neither number changes if you build the tool yourself. If anything the DIY route makes it worse, because you have now added a second artefact to verify: the model, and the application that produced it.

This is the part of the objection that argues against everyone in the category, us included. "We make you faster" is the wrong pitch in a market where speed was never the constraint. The right question is whether the second visit to the model is cheaper than the first, and most tools, self-built or purchased, have no answer to it. I wrote about where the verification hours actually go separately.

The counter-argument I cannot dismiss

Here is the strongest objection to everything above, and I have not found a way around it.

For someone who codes, a repository is already versioned, tested, reviewable and auditable. Git gives you history, diffs, branches, and a review step before anything merges. If the logic of your model lives in a repo, "you need a layer that makes your structure persistent" is a solved problem to which you already own the solution.

One practitioner has pushed this further than the rest: define the model in code, unit-test the structure, and compile a spreadsheet as the output. The logic is a durable asset. The workbook is a build artefact. It is a coherent architecture and it is genuinely competitive with what a product like ours offers.

Where it still leaks, and this is the narrow ground I would defend: the state does not live in the repo. Every override, every "actually, use 4.2% for this entity this quarter", happens in a cell of the generated spreadsheet, outside version control and without a trace. Which is precisely the complaint that sent him away from templates in the first place.

So the argument for a layer is not persistence in the abstract. Persistence of method is solved, and the ecosystem has solved it well: skills, context files, prompt libraries, repos. What is not solved is the persistence of the thing those methods operate on, with its state, its history and its overrides intact. I went through the six things that have to survive a new session elsewhere.

A decision test you can run this week

Forget the vendor comparison. Answer these four in order.

1. Would two people doing this by hand get the same answer? If yes and you will run it more than three times, build it. Stop reading.
2. Does the artefact leave the building? If a board, a lender or an auditor opens it, the export is the product, not the app. Test what comes out before you commit to what goes in.
3. How many times will this same logic be instantiated? Once is a script. Ten times is a structure problem, and a script becomes ten scripts that drift.
4. Can a second person change one rule without calling the first? If not, you have a maintenance liability with a six-month fuse, regardless of how it was built.

Three of those four favour building. That is not a rhetorical concession, it is the actual distribution. The fourth is where the money is.

Where Layerz sits in this

Layerz does not compete with the agent. It gives the agent something to work on that survives the session.

The structure of a model, meaning what depends on what and which assumption drives which line, is stored separately from the values sitting on top of it. It is versioned, and you can diff two versions. Claude drives it from the outside over MCP, so the same model can be read and modified across sessions, across people, and across clients, without being described into existence again each time.

The Excel export is a clean, standard workbook with live formulas, and it is never paywalled. Your own model exports without a watermark, because the file that goes to the other side has to be yours.

And if you build it yourself instead, that is a legitimate outcome. The specification is public: FINANCE.md is an open standard, the model format exports as JSON, and there is a raw view of everything. Being easy to leave is the only credible answer to "why not do it myself" that does not depend on you taking my word for it.

Further reading: How to Stop AI From Hardcoding Values in a Financial Model · Finance Software Went Closed. Developer Tools Went Open. · The Verification Tax · Persistent Memory for a Financial Model · AI Financial Model Risk and Governance: Statistics

Layerz keeps a financial model as structure separate from data, so an agent can change it without rebuilding it. Excel export is clean, standard, and never paywalled. Explore Layerz →