Every finance team runs on technical debt. It's the mission-critical spreadsheet built by an employee who left two years ago - the one with formulas so fragile that nobody dares touch them. Everyone just works around it.
While AI was supposed to eliminate these manual headaches, it is actually shining a spotlight on our existing tech debt. "Vibe coding" promises that anyone can build a working app in an afternoon without opening an engineering ticket. But that means that internal tools are multiplying faster than teams can track them.
At the F Suite Senior CFO Summit, I joined John Glasgow of Campfire, Amy Lee of Aerospike, and Ed Barrow of Cloud Capital to tackle this issue. The consensus? We must temper our enthusiasm for vibe-coded finance tools. They are easy to make, but without governance, they introduce known, and unknown, risks.
The Hidden Risks of Build vs. Buy in the AI Era
AI has turned "we can build that ourselves" into the default response for modern finance teams. The pitch sounds great on paper: skip the $50,000 vendor contract, spend a weekend vibe coding, and save money.
However, bypassing standard procurement and security reviews exposes companies to three potential failure points:
Security Exposure: Financial data is far too sensitive for lax security practices. Vibe-coded tools get built to work, not to be safe. They routinely end up with weak or shared logins, database keys sitting in plain view in the browser, no logging or auditing functions, and broader access to underlying data. Vibe-coded tools generally skip traditional procurement processes, which means tools are put into production with severe vulnerabilities—like one CFO who found an internal finance tool gated by a shared password made of employees' phone numbers.
Continuity Risk: Vibe-coded tools usually have a single builder, zero documentation, and no backup plan. If a single employee's side-project runs critical logic like commission payouts, the operation breaks the moment that employee takes a vacation or resigns.
The Cost Illusion: A build often wins on price because internal labor isn't invoiced. Spending two weeks of an employee's time is real money at a fully loaded cost rate. Worse, ongoing maintenance, API updates, and schema changes fall indefinitely on an internal resource, pulling them away from their actual job. And let's not forget about token cost!
Do the Math Before You Build
If cost is the primary justification for building an internal tool, test the math accurately. Price an internal build just as you would an external platform:
Labor: Calculate the builder's hours using fully loaded costs, not base salary.
Engineering: Add the cost of IT or engineering time required to review, deploy, and host the app safely.
Maintenance & Rebuilds: Account for ongoing maintenance and the cost to maintain or rebuild the tool.
Compare that total against the vendor quote. Building makes sense when dealing with a narrow scope, stable inputs, non-sensitive data, and a builder who isn't essential to the monthly close process. But when you don't have one or more of those, the decision should be critically evaluated.
Tier the Tool Before You Govern It
Good governance doesn't mean forcing every micro-tool through a full SOC 2 audit. A dashboard that charts your own team's headcount doesn't need what a tool touching customer bank details needs. But most companies apply the same non-answer to both: nothing.
The fix is to sort tools before you govern them. Key questions to consider:
What data can the tool reach? This is data that is either “entered into” the tool or “accessed by” the tool. What is the sensitivity of that data?
What privileges does it have? Read, write, ship? Reading your ERP is a confidentiality question. Writing to it, triggering a payment, or sending something outbound is an integrity question, and integrity failures are much harder to unwind.
Who is using the tool? Is this a tool one user created to assist their own work or will it be shared with the entire organization? Is the tool externally-facing (e.g, a customer or board member may use it)?
What’s the use case(s)? Those “mission-critical” workflows require attention. And you also need to determine whether the tool is being used for a “high-risk” use case under relevant AI laws. For use cases within this category, the rules are fairly prescriptive about how transparency and oversight need to be built into the product.
The Vendor Test for Internal Tools
Before deploying any vibe-coded app, subject it to the Vendor Test:
"Would you sign a vendor contract if they offered software with a shared phone-number password, hosted on an unmonitored server, with zero documentation?"
If the answer is no, your internal tool shouldn't pass either. Ask if you would approve the build if the internal labor was presented as an invoice.
Your team will continue to build vibe-coded tools—and they should. The goal of governance is simply making sure those tools pass the test before something breaks, rather than after.
Want to join conversations like this at our next F Suite events? Apply for membership today.