Tackling your board's next big question

Are CFO's really building their own software?

March 20 | 8 min read | By Tim Cooper

TLDR;

AI‑driven “vibe coding” is tempting CFOs with the promise of fast, cheap, tailored tools. Are homegrown apps a realistic prospect for most finance leaders and their teams? Is vibe-coding really cheaper - or safe enough - for serious finance teams? While some finance professionals are experimenting with building their own apps, is it leading to real durable software? Do homegrown tools come with hidden privacy and compliance risks? 

This is part one of a two-part series. Next week, we’ll dig deeper into the risks of vibe coding, such as hidden bugs and data security, and look at best practices for building your own AI tools. Today we’ll focus on the bull case for vibecoding:

  • Buy core, build edge – No-one is building their own ERP, but there could be value in building around it.

  • War stories – Finance teams carry regret and scars from decades of tech overpromising and underdelivering. Is vibe coding any different and should that color their judgment?

  • Crucial judgments – It’s essential to understand how your needs might change and whether you can resource maintenance long-term to avoid broken tools.

Fora scaled revenue 3x in a year - without scaling finance headcount

Join Campfire and Ramp for a live fireside chat with Fora's Controller, Adam Schneider, on how they processed millions of dollars and hundreds of thousands of transaction lines monthly while cutting close time by 20%.

Walk away with the exact stack, automations, and mindset behind running a lean finance team at hypergrowth speed.

Joel Campbell, CFO at payments platform TreviPay, describes himself as a simple guy with a heavy mandate. Until now, he and his team haven’t had much time for experimental AI projects like building in-house software.

But, like many of his peers, Campbell recognizes the potential in homegrown apps. His team recently started building their own financial management reporting tool that draws data from the company’s systems and automates it into a reporting dashboard.  

“We used PowerBI to collect and collate the internal data, update it continuously, and create the dashboard. We intend to migrate what we’ve created to an AI tool, likely Claude, in which we can use plain language prompts and create agents," he said.

Finance vibe coders are building their own bespoke finance applications in-house. This DIY solution could enable finance functions to build highly customized tools, protect their IP and data, save money on costly consultants and subscriptions; and most importantly get to the result they need faster.

“Outside the core ledger and transaction backbone, building is increasingly attractive. The best finance leaders I know aren’t ignoring this shift. They are deploying small, focused teams that combine deep finance knowledge with technical and AI capability to experiment quickly,” Brian Keare, CFO at revenue lifecycle platform Nue, said. 

So what is vibe coding’s potential? A Baytech Consulting report doesn’t hold the hyperbole, declaring “CFOs are building not buying” in a “vibe coding revolution”. The balance has tilted as tool creation costs have plummeted 80%, while the expense of bought solutions has rocketed up to 50%, it said.

One thing Baytech didn’t acknowledge was that bought Saas tools are increasingly AI-enabled. This could make them more efficient than homegrown equivalents by making functions faster and more productive but in a safe, tried and tested environment, with fewer risks. 

So is vibe coding really a credible solution for building enterprise grade software? Does custom development provide a true strategic advantage over the new generation of AI-powered SaaS?

Experiment – but fail the right way

When weighing buy vs. build it’s crucial to understand how your needs might change over three to five years. If teams come to you with a build idea, make sure the ongoing maintenance and development needs are well understood and you have the resources to cover them. Or you could be stuck with broken tools. And that can be an expensive mistake. 

Research by AI developer AgileSoftLabs claims 70% of custom software projects “should have been bought”; and 30% of purchases “should have been custom builds”.

Building when you should buy typically costs more long-term than making the opposite mistake. Lack of strategic alignment for the project and drastically underestimating the ongoing burden of custom software – including maintenance, updates, and security patches – are the two biggest errors, said the developer.

And if you bite off more than you can chew, you risk having to call in expert engineers to bail you out, a resource that could be focused on more business critical issues.

AgileSoftLabs gives examples of bought customer support and employee onboarding systems to automate non-differentiating standard or easily adaptable processes. Both brought large, rapid productivity gains due to market availability of mature, fast-to-implement systems. The question is: why isn’t this approach good enough for finance?

Do your homework

In-house development is not new. Before AI coding made time-to-prototype faster, building homegrown tools involved more rigid and time-consuming processes. Many finance teams carry the scars of previous project overruns and maintenance issues.

Todd Laddusaw, CFO at treasury software provider Kyriba, said: “I talk to many CFOs about buy or build. Most have at least one ‘we should have bought it’ story.” Two common tales are:

  • In-house developers exit, leaving you to maintain code that no one understands. Updates become archaeology projects.

  • By the time you've finished your custom build, software vendors are two generations ahead. You can’t catch up.”

Research into AI coding illustrates the care needed to use it successfully, even for experienced programmers. 

Multiple studies show more security vulnerabilities in AI generated code. And, rather than working faster, developers were actually 19% slower when using AI tools, according to an METR study. This was likely due to the tools having insufficient context and innate knowledge, or low reliability, especially in large and complex environments.

Now, while this will change as the technology develops and engineers better understand how to work with it. But it does beg the question if the pros are - today at least - being slowed by AI, CFOs need to wonder if it’s just too early to let their team loose on Claude Code.

Buy the core and build the edges

For core finance systems – ERP, FP&A, AR, and AP – the best bought solutions provide stability, scalability, and adaptability. Not to mention engineer experience and ongoing support.

Building one of these yourself would be a large, complex project and create huge risk in areas such as:

  • Maintenance and development responsibility

  • Governance and auditability

  • Security and compliance

But building might make more sense in niche areas or specific workflows, said Rob Konferowicz, founder at advisory firm CFO Shortlist. He gave two examples: “Say you’re a two-person FP&A team wanting to automate part of your reporting. You’re too small for a commercial offering. But the task is too complex for Excel. It makes sense to vibe code something.”

“Or you want to automate some forecasting. Extracting the data you need is repetitive and manual. With AI, you could build [a solution for] that in a day with no technical background. The tools have improved like the difference between night and day in the last six months.” 

Playing with data

In TreviPay’s case, Campbell certainly isn’t considering building core systems such as ERP, payments, and accounts receivable in-house. Tried and tested purchased solutions with embedded compliance and other critical functions are essential for the backbone of your finance operation, he said.

So how’s it going with his new reporting tool?

The dashboard looks good, he said. “While we’ve not perfected the process, we anticipate our FP&A team will be able to create value-added reporting for senior management in hours or days instead of days or weeks. The nice thing is if you own the data, you can play with it and get it to do other things for you.”

This hints at one of the main challenges that Campbell and his team anticipated. The project would not have worked without an initiative last summer to build a data lake containing information exclusively for the finance team’s use.

“Previously we had a data warehouse that numerous people could access, which was fraught with challenges,” said Campbell. “So we had to overcome that. For every CFO building a tool, the challenge is do you have access to the right data? Is it clean, accurate and validated?

“So it’s not without additional work to figure out how to use this tool correctly and get the right data into it. But as AI and prompting improves, you’ll see more tools developed internally.”

Is it worth it?

Like Campbell, busy CFOs remain skeptical about self-built tools and still mostly prefer to buy tried and tested solutions they can configure in a day or two, then get moving. But the options for experimentation are increasing, especially for tools that need greater customization, give you differentiation, or don’t exist off-the-shelf with the functionality you need.

Reading the Room…

  1. Data boundaries. Which data classifications are permissible in vibe-coded environments, and who has authority to approve exceptions?

  2. Security and maintenance. Can we realistically audit, patch, and own code we didn't meaningfully write, and what is our remediation process when vulnerabilities emerge?

  3. Build discipline. Is there a mandatory market scan before anyone builds, and are we honest about whether internal efforts can compete with funded, focused vendors?

  4. Safe experimentation. Do we have a sandboxed environment with clear, enforced graduation criteria before anything touches production?

  5. Governance and policy. Is there a permitted-use policy in place, does every builder know the boundaries, and who has authority to pause or kill an initiative?

  6. Organizational maturity. Do we have the talent, processes, and culture to move fast without risks surfacing at board level after the fact?

  7. Capital allocation. How does vibe coding sit within our broader technology investment strategy, and are we measuring its true cost and return?

Boardroom Brief is presented by The Secret CFO Network

Want more? Check out the Secret CFO’s deep dive into the mechanics of CFO storytelling in our most recent Playbook, and find out what to do when the CEO plays fast and loose with expenses in last week’s Mailbag.

And don’t miss the next Boardroom Brief on March 26th, where we’ll dig deeper into the risks of building your own AI tools.

If you found this helpful, please forward it to your fellow finance leaders (and maybe even your Board). If this was forwarded to you, you can make sure you receive the next edition by subscribing here.