Artificial intelligence is shifting the economics of build-versus-buy as more accounting firms turn to apps created not by software vendors but code generators such as Claude, Replit or Cursor. While firms had always made bespoke applications for their own use, the ease and accessibility of so-called "vibe coding" for even non-technical staff has dramatically reduced the time and money needed to develop them.
"This is the first year where people are really thinking 'Do I actually need to buy? Do I actually need this specialized vendor?' Whereas before they might have entertained that in the past. But now some are saying, 'Oh, actually, I can just double down on building things through Claude Code and APIs and agents.'" said Ellen Choi, founder and CEO of AI-focused accounting consultancy Edgefield Group.
There's a lot of reasons for this trend. Cost is a big one. If a firm can vibe code its own solution, it won't need to pay thousands per month on licensing and support fees, it will only have the cost of the code generator itself. Kacee Johnson, fintech innovation leader with AI-specific business consultancy Radical as well as the co-founder and executive director of the AI Native Accounting Foundation, began noticing this trend because of rising reports of vendor pushback.
"When I first started to notice, it was because so many vendors were getting pushback. They were being told, 'Hey, we're not going to spend 300 bucks per month per user on this because we can vibe code it ourselves. I'm sure it's not as pretty as your UI, and maybe doesn't have all the functionality you guys have, but I don't need all of that. I can vibe code this. It's a fraction of the cost. It's to my specification,'" she said.
Mike DeKock, founder and CEO of MJD Advisors and an enthusiastic user of AI code generators himself, noted that he has saved his firm hundreds of thousands of dollars this way. He said he recently met with a major audit solutions platform vendor, but felt the price was too high compared to AI code generators. They quoted him $300,000 a year. He noted that the annual cost for his AI code generator, Retool, is not even $30,000. He ultimately decided not to go with the platform in favor of his own AI-coded solution. But even when a vendor gives a good price, the question of whether he could simply get AI to fulfill the same function is now often on his mind.
"Two months ago, I had an IT audit software company come to me and demo their product. And it was awesome. And they gave me a good price because they thought we could collaborate on it. But I took about six hours and built it myself," he said.
He added some important caveats. It's "obviously" not the same level of sophistication as the vendor-offered solution. At the same time, however, his firm's workflows did not require it. What the AI built, he said, met their specific needs to the exact level they required. He admitted that the program is still buggy and is still in the process of being cleaned up, but ultimately he felt it was worth it.
"At the end of the day, we're going to own it, we're going to control it, we're going to be able to build on it the way that we want," he said.
This plays into another motivation: custom software fitted for exact circumstances. Randy Nail, CEO of Top 100 firm Hogan Taylor, noted that it's a common experience for tools to either do more than is needed or not do what a firm needs exactly how they need it. While this has always been true in the software world, vibe coding allows uses to do something about it, whether that means plugging holes in existing solutions or developing entirely new ones.
"Somebody like me, who has no engineering experience at all, would have a problem, and I would ask a large language model, or I would ask a tool that interacts with a large language model, just in my own language: 'Here's my problem, solve this for me, or design a piece of software or an app,'" he said.
David Brown, business solutions architect for Abacus Technologies, the technology arm of Top 100 Firm BMSS, raised a similar point. They began with apps that filled gaps in their current solutions, with early experiments sitting on top of them for things like providing a different interface or accessing APIs. But as they began racking up more wins in this area, they began wondering how far they could take it.
"Within some of our smaller niche service lines that have pretty specialized needs, a couple of the people who are using Claude Cowork said, 'What if we just built the solution that nobody else is really building out there for us?'" he said.
Another major aspect behind the rise of vibe coding is that certain accountants are just very interested in it, even firm leaders. Johnson, from the AI Native Accounting Foundation, noted that those who vibe code applications in their everyday life are likely to bring it to their firms as well.
"I think it's primarily that there's somebody in the firm who actually genuinely enjoys vibe coding, like they would do regardless, and so they're taking the initiative. I don't see it as structured discussions in firms yet about how we should approach this. It seems to be somebody raising their hand, they had an idea, they went out and came back with a proof of concept and a demo and said, 'Look, this is what I built and I think we should use this,'" she said.
Security, support, scaling
But while vibe-coded apps solve a lot of old problems, even those aforementioned enthusiasts will concede that they introduce some new ones that will need to be addressed by any firm leader who intends to take this seriously.
For one, while the extreme customizability of vibe-coded apps offer definite advantages in the specific use case for which they were made, they can suffer when outside that context.
"It's going to work for that extremely specific set of configurations, but it's gonna break the moment you try to do anything that is any different than whatever that particular practitioner has spaghetti-coded her way into that app," said Choi, from Edgefield.
So while an AI-generated app might be useful, the extreme specificity under which they are produced can make them difficult to scale to the entire firm, as Brown from Abacus Technologies learned early in his firm's journey.
"The first couple of iterations, when we decided we could take what was built by that individual to solve that problem and scale it for the firm, we found pretty quickly that's not a viable solution. The methodology doesn't fit with the rest of the security architecture, and the way we'd manage it, the governance, it doesn't have any of that structure built into it," he said.
This plays into another issue vibe coding raises: Who will actually maintain this app? Software can break in a wide variety of ways and so must be maintained. People need to patch vulnerabilities, update third-party integrations, oversee data migrations, fix bugs, address user problems and much more. Usually it's the vendor who takes care of these things. But there is no such support with AI-generated apps.
"Who does support? OK, so now somebody else in the firm is using it, and something breaks. You can't go in and submit a ticket unless you're a massive firm that has that kind of setup. So, how does that work?" said Johnson, from Radical.
For DeKock of MJD Advisors, his answer to Johnson's question would be himself. As the one who developed the apps, he also spends "a lot of time fixing bugs and doing maintenance." But this leads into another common challenge: Oftentimes, the only one who knows how these apps work is the one person who prompted them into existence. DeKock admitted this maintenance isn't exactly the sort of thing the CEO of a CPA firm should be doing, but no one else has his level of understanding. Asked what people would do if he were in the hospital at the time when one of his apps stopped working, he was blunt: "They would have to call me at the hospital," he said.
As the head of a SOC 2 specialist firm, he's well aware of the risk his centrality poses. While thankfully he's healthy now, DeKock acknowledged, "That's a huge exposure." So rather than sitting around waiting for the other shoe to drop, he's working to address this risk by turning to professionals, including a recently-hired fractional chief technology officer.
"That's why we're getting a developer team involved and getting the CTO involved, and part of that process has been to document everything in a way where if we did have to onboard someone, or we did have to understand something, someone else could do it … . And so trying to get that transitioned is also certainly a focus," he said.
Brown reported a similar approach. While the firm has begun with vibe coding apps, they had already had a professional development team for years. He said that accountants should not be spending their time acting as IT workers for their apps when they have actual IT workers who can fill that role.
"When you start thinking about pieces being scalable, rolled out to the entire firm or even a subset of the firm, somebody's got to support it. And it's not going to be the professional that helped build it. They don't need to be supporting the app, they need to be doing client-facing or other work. And so our support team has to be able to actually provide the support for it to keep the app functioning the way it's supposed to," he said.
This is the general approach Choi has seen for firms that actually want to scale their AI-generated apps to something approaching an organization-wide solution. While AI can produce a good prototype or narrow-use app, it can be difficult to scale it for wider use. She said one firm she visited had an engineer working with a partner on scaling up a vibe-coded app; two months later, even working together, they still can't figure it out "whatever weird configuration you're doing with your extremely specific setup."
"Someone can vibe code and have a prototype but you need an actual technical person who knows what they're doing to sit alongside them and define and capture the required specifications. So it's almost like trying to make the practitioner a better product manager rather than a mediocre engineer," she said.
Ambition, analysis, awareness
This speaks to the observation from Johnson that the firms doing this well are not heedlessly replacing their entire tech stack after telling Claude "go make me a good app" and accepting whatever the model spits out. Yes, she has witnessed some firms making many tragic mistakes with vibe-coded apps. But she has also witnessed other firms taking a deliberate, methodical approach that is little different from responsible software development practices anywhere else.
"They have processes, they have procedures, they have documentation, they have agreements with the employees, and it goes through an evaluation process beyond that first demo. They're not doing it with live client data in that first iteration. … They're doing the testing. It's not just a willy-nilly, 'Hey, this worked great on this one thing, so sure, let's use it,'" she said.
This is what firm leaders like Brown, from Abacus, do to ensure their vibe-coding efforts do not cause more problems than they solve. Understanding the stakes at hand, his firm has developed a structured, intentional process for building vibe-coded apps and then, if they have potential, scaling them up to the whole firm. He emphasized that they are, under no circumstances, using the vibe-coded apps as the final output in any situation.
"What we've done is put some guardrails and parameters around them. So if we are going to be developing something that we expect to scale, then whoever got the idea … gets paired with somebody who's actually on the development team, and they say, 'Yes this is great, but we've got to make sure that it has this security structure and protocol, we got to make sure that the it's building on this programming language,'" he said.
MJD's DeKock similarly takes care to do things safely and consider the implications of his AI creations. He even noted he dislikes the term "vibe coding" because it implies something very different than what he does.
"I don't like the term 'vibe code,' I don't tell people I'm a vibe coder. There is a very Wild West approach to that, and that's not how I've approached this at all. It's been very thoughtful and careful. I'm always asking both ChatGPT and Claud, 'What are the security risks?'" he said.
Firms taking this approach tend to be very mindful of risk and so usually are not replacing major systems with AI-generated software. Instead they most commonly make internally facing apps that indirectly support their work.
"So much of it is just administrative. It's not even calculating the tax but all the work of gathering the documents, keeping track of all the clients, ingesting data correctly, auto-classifying it correctly, doing the OCR correctly. Once you get through the security and compliance, it's more like administrative road work that firms have had for so long that now you could vibe code things with AI," said Choi.
DeKock echoed this when saying that development is slow, iterative and — crucially — internally facing. Anything that touches client data, especially anything that requires the exchange of sensitive information, is done in enterprise solutions with strong security support. He noted this is a big part of "just how careful, how slow, we can go and make little changes instead of big shifts." While he is now planning to use AI to develop client-facing applications as well, he stressed he will not be doing this alone.
"We're now starting to work on some external-facing stuff. With that, I've brought on a fractional CTO, and we're working with some outside developers, so once we're going to start doing the hard stuff, the more dangerous stuff, it was like, 'Let's get a professional involved' at that point," he said.
Hogan Taylor's Nail similarly stressed that they're keeping risk in mind when working with AI-generated apps, keeping things in what he called the "micro" realm.
"We definitely have vibe coding going on at Hogan Taylor as it relates to solving some kind of unique issues or problems in a micro kind of format. We're not going to take on a big practice management system, or a tax software system, or even a workflow that is at scale over our 425 people," he said.
This is generally the approach Johnson encourages. The closer it gets to a client-facing function, the more the firm must account for the risks. Conversely, the further away an AI-generated app is from systems of real consequence, the safer it generally is to use.
"If it's being used for just one client, and it's in a secure environment, I don't think it's as big of an issue. It's when they're going to use it across multiple clients, because you don't know how that model is going to confuse and have data leakage between different clients. So I think [apps that connect to] the foundational systems, general ledgers, like tax prep and audit software, even like practice management, [are riskier]," she said.
Escalation, evolution, emergence
As of now, there are not a lot of firms actually doing this, and even among those that do vibe code their own apps, only a minority are doing so at any appreciable scale. Even the accounting leaders who have embraced vice coding still use a lot of vendor-offered solutions. Choi noted that even for those firms this is all still very experimental. But it is unlikely it will stay this way for long, as Choi noted firms are already eyeing AI as a way to cut costs and rationalize vendor relations.
"In terms of actually building more deterministic solutions that actually provide firm-wide benefits, it's still very early in testing and implementation. But the bigger firms, for sure, have this idea of, 'We are using AI to build more to solve for more problems in a way where we don't even need certain types of vendors' or 'We don't want to pay for certain types of vendors,'" she said. Emphasizing the novelty of the situation, she added, "This is a new possibility that was not even on the radar of firms."
Johnson noted that it behooves firms, even if they choose not to vibe-code solutions themselves, to be aware of how they work and the risks involved. This is because even if the firm itself does not use AI coding, they will almost certainly have clients who do, which could lead to complications with their own software. She brought up a firm whose client used their own custom ledger software that could not properly communicate with the firm's systems. While this may have been the first time the firm encountered this, Johnson felt it was unlikely to be the last, which could mean trouble for practitioners.
"Come on," she said, "the accountants don't want to have to clean that up."
