Building an accounting tool with AI is only the beginning of making it useful, secure, and sustainable.
Sponsored by Radical Pricing by the Radical CPA, Jody Padar | See Today’s Special Offer
Subscribe to CPA Trendlines podcasts anywhere: Apple, Google/YouTube, Spotify, iHeart, Deezer, Amazon Music, Audible, Player FM, Audacy, RSS.
Innovation Insights
With Donny Shimamoto and Byron Patrick
Center for Accounting Transformation
An accountant builds a dashboard that pulls information from several systems. A proposal generator turns service selections into a polished PDF. A homemade utility eliminates a tedious step in the monthly close.
Then comes the question that changes everything: How do I let my team use it?
In this episode of Innovation Insights, Donny Shimamoto and Byron Patrick explore the distance between a promising personal tool and software an accounting team can depend on.
AI makes building easier, they say, but sharing, securing, supporting, and maintaining what you build requires a different level of preparation.
For accountants eager to experiment with AI agents and “vibe coding” — using natural-language instructions to have AI generate code — the conversation offers both encouragement and a reality check.
The first challenge arrives after the first success
Patrick, CPA.CITP, senior product manager at Karbon and founder and part-time educator at TB Academy, works on accounting and client accounting services products that help streamline recurring work. He sees plenty of ingenuity among accountants building their own tools.
He also sees a recurring blind spot.
“They build something that they can use,” Patrick says. “And then they go, now how do I give my team access to this?”
A self-contained utility can meet its creator’s needs. Making it available to others may introduce servers, databases, authentication, and connections to multiple systems. What begins as a personal productivity project becomes a software deployment project.
Shimamoto, CPA.CITP, CGMA, founder and managing director of IntrapriseTechKnowlogies LLC and founder and inspiration architect for the Center for Accounting Transformation, frames the discussion around accountants who want to build their own solutions, particularly those in smaller firms.
The appeal is clear: Professionals who understand the work can now experiment with tools that address frustrations they know firsthand. The challenge is recognizing when the project grows beyond their expertise.
Every extra feature adds another obligation
Even a straightforward tool can become difficult to share when its creator keeps adding capabilities.
Patrick describes the result as a “Frankenstein of systems.” One useful function inspires another, then another. Before long, the builder understands a complicated collection of buttons, steps, and workarounds that colleagues encounter for the first time. Accountants recognize scope creep in client engagements. Patrick cautions that the same pattern appears in homemade software.
A proposal generator illustrates the progression. A simple tool lets someone select services, apply a pricing table, and produce a PDF. Then the creator adds AI-generated executive summaries or presentation slides. The original, tightly defined solution becomes something much larger. Patrick favors tools with a specific purpose and a clear boundary. Every addition creates more to explain, test, secure, and eventually maintain.
A training video cannot carry the entire rollout
Shimamoto raises a familiar response: What if the creator writes instructions and trains the handful of people who need the tool? Patrick acknowledges that successful implementation is possible. But he cautions against underestimating the effort.
“I could build you the greatest technology platform on the planet, but if nobody can use it, it is useless,” he says.
A video or instruction manual can support adoption. It cannot automatically make a confusing tool intuitive or ensure that colleagues understand how it fits into their work. The creator has the benefit of knowing why each feature exists and how the system develops. Other users need a clear experience, practical guidance, and support when something goes wrong.
The real test extends beyond whether the software runs: Can the team use it consistently and confidently?
A working webpage leaves important questions unanswered
Patrick recalls watching someone demonstrate utilities built for an accounting firm. He copied the website address and discovered he could access the tools from his own computer. He did not investigate whether client information was present. The accessibility itself raised a concern.
The example exposes a weakness in the rush to share homemade tools: A builder may know how to reach the application without understanding who else can reach it or how its information is protected.
Shimamoto points out that the environment differs from the familiar experience of creating and sharing a spreadsheet macro. With an online tool, accountants need to understand where information goes and what sits behind the interface.
Patrick also cautions against assuming that an application is secure simply because it appears to operate on a local device. The relevant questions include what information the tool accesses, what services it connects to, and where information travels.
Both speakers urge accountants to involve people with security and privacy expertise.
Patrick applies that standard to his own work. He describes building an internal utility for Karbon, then bringing it to security professionals and engineers for review before making it broadly available or introducing company information. For smaller firms, Shimamoto suggests involving a qualified managed service provider. The review needs to address what the tool does, what it accesses, and how those activities are controlled.
Give agents clear boundaries
The conversation becomes more consequential when tools can take action across connected systems. Shimamoto warns that agents operating through a user’s credentials may have access to information and applications the user can reach. He describes pilots that use protective boundaries to restrict agent activity.
His preferred approach is to define permitted actions explicitly.
“Only tell it what it can do,” he says.
Patrick agrees that approved connections and capabilities deserve deliberate review. He also points to the human habit of clicking through permission requests without considering their implications.
For accounting leaders, the discussion raises a practical question: Does the team understand what it authorizes when it connects a tool or approves an action?
Your prototype can start a better vendor conversation
Building something yourself does not have to end with maintaining it yourself. Patrick encourages accountants to show software providers the gaps they are trying to fill. A prototype can make a request concrete, demonstrating the information, workflow, or output the firm needs.
Shimamoto reinforces the point. Even with a software development team available, he takes requests back to vendors. He describes responsive providers incorporating customer feedback more quickly as their own development capabilities improve. A homemade tool can therefore serve as a useful proof of concept and a starting point for collaboration.
Plan for the months after the demo
The final challenge may be the easiest to overlook while a new tool is delivering its first successful result: Someone has to keep it working.
“It’s really easy to build something today,” Patrick says. “But maintaining that three months from now, six months from now, a year from now, is a totally different story.”
Shimamoto connects that obligation to scope creep. As features accumulate, the maintenance burden grows with them.
Both speakers encourage experimentation with a manageable starting point. Patrick recommends lower-risk projects that do not require private information. Shimamoto describes testing internal administrative processes while keeping client data handling outside those initial experiments. Their advice gives accountants permission to learn without treating every successful experiment as a finished product.
For professionals feeling pressure to keep pace with AI, the episode offers a more useful measure of progress: understanding what a tool can do, what it requires, and when to bring in help. The first working demo is a milestone. Making the tool dependable for everyone who uses it is the work that follows.
9 Key Takeaways
- Define the audience first. Decide whether the tool serves one person or an entire team before making design and hosting decisions.
- Keep the purpose narrow. Set a clear scope, and evaluate what each added feature creates in training, security, and maintenance work.
- Test with another user. Have someone who does not build the tool try it, and use their experience to identify confusing steps.
- Understand the data flow. Know where information is stored, who can access it, and which systems the tool connects to.
- Bring in qualified reviewers. Involve security and technical professionals before introducing sensitive information or expanding access.
- Set explicit agent permissions. Review approved actions and connections instead of routinely accepting permission requests.
- Show vendors the problem. Use a prototype to demonstrate a missing capability and discuss whether your provider can address it.
- Assign maintenance responsibility. Identify who will support the tool, troubleshoot problems, and manage future changes.
- Start with manageable experiments. Follow the speakers’ recommendation to explore internal administrative tasks that do not require private client information.