AI lowered the cost of building internal tools for ABA providers. It did not lower the HIPAA obligations, the maintenance, or the security failure rate attached.
Key Takeaways
- Building is now plausible for providers that could never build before: An operator four years into running an ABA company told a Boston audience her team had assembled its own systems in ClickUp, and that AI had made the work far easier than expected. The constraint that used to settle this question, engineering capacity, has loosened.
- The HIPAA obligation does not shrink with the build cost: Security duties attach to a system regardless of who wrote it, and a proposed Security Rule overhaul would make encryption, multifactor authentication, and annual asset inventories mandatory rather than discretionary. That rule is still proposed, with final action now pushed to July 2027.
- AI code security has not improved with AI code speed: Veracode’s testing across more than 100 large language models found syntax pass rates climbing toward 95 percent while security pass rates stayed flat between roughly 45 and 55 percent. Code that compiles is not code that is safe near protected health information.
- The usable question is resource allocation, not capability: Jeffrey Morelli’s framework asks what the highest-leverage use of scarce internal resources is, and where the system will break in the next six to twelve months. Both answers change as an organization grows.
Near the end of an hour spent dissecting software failure at ABA CARES in Boston last month, an operator in the audience stood up with a question none of the five panelists had prepared for.
She had been running an ABA company for about four years. Early on, she said, she had done what curious owners do: taken every vendor meeting, tried things, assumed anything difficult was learnable. What she had concluded since was that running a company is closer to editing than to acquiring. “I think your main job is just to be the Editor in Chief of your company,” she said, “not taking in more, but being the person to edit out what you don’t need, because your time is precious.”
She had scaled fast, broken some things, pulled certain things back, and now wanted to regroup with more intention. Two facts were pulling against each other. The first was that any design flaw in a platform she evaluated today might be fixed by the vendor before she finished implementing it, because the market is moving that quickly. The second was that her own team had started building. They had stood up their own systems in ClickUp, working with an outside developer, and found it easier than it had any right to be. “Seeing how we’re able to build things out with so much more ease because of AI,” she said. So which was it: is she smarter now and able to choose a better platform, or is the timing simply wrong?
Jeffrey Morelli took the question first, and answered it with a story against his own interest. Morelli is Chief Executive Officer and co-founder of Silna, which sells front-end revenue cycle software to behavioral health providers, and one of five vendors who spent the session telling buyers how to make their own sales process harder to survive. Last year, he said, his own company needed a better way to communicate with insurance companies. He had a limited engineering bench and a longer list of things he would rather it work on, so he bought. “I’m just going to go and buy a vendor and a solution because I don’t want to worry about that today,” he said, reconstructing the reasoning. “That’s not where I want to dedicate resources.”
Nine months later, at scale, the purchased system turned out to be too limited. “It only took our engineering team about two weeks to just replace the entire vendor,” he said, “and now all communication is being handled internally.” The lesson he drew was not that buying had been a mistake. It was that the decision had a shelf life, and that the shelf life keeps getting shorter.
Why the ABA Software Build Versus Buy Calculation Moved
For most of this market’s history, building was theoretical for anyone below platform scale. A 30-clinic provider did not employ software engineers, and hiring them dwarfed any license fee. That constraint did most of the deciding, which meant operators rarely had to articulate why they were buying. They bought because building was not available.
It is available now, at least in the shallow end: scheduling logic, intake trackers, credentialing dashboards, and the spreadsheets that accumulate alongside a practice management system are within reach of a motivated operations lead and a coding assistant. That is why the question came from the floor rather than from the panel.
Morelli’s framework for answering it has two parts, and neither is about whether the thing can be built. The first is a question about scarcity: “What is the highest leverage use of time with the limited resources you have internally,” he said, “and how do you focus dedicated on that and not other workflows?” The second is a question about time: “Where is the system going to break in the next six to 12 months, and how do you forward place that bet?”
His own reversal fits inside both. Buying was correct while engineering capacity was the binding constraint and insurance communication was not the thing likely to break next. Building became correct nine months later, when scale had turned the vendor into the constraint. “As you scale, that time horizon of where you’re willing to place bets changes,” he said. The implication is uncomfortable but clarifying: there is no permanently correct answer, only one that fits the organization’s current size and its next twelve months. The same logic runs upward through the market, which is why platforms keep absorbing the tools they once licensed, as Motivity did in bringing practice management fully in house.
What Building ABA Software In-House Obligates a Provider To Under HIPAA
Charlene Kurth, Chief Operating Officer at Office Puzzle, gave the counterargument from inside a software company, which is a useful vantage because her engineers make the same offer to her. “Our engineers are like, well, we could build that,” she said. “Do we want to get into also building our own products when we’re supposed to be building products for our customers?”
Her objection is not to the building. It is to the accounting. “Thinking about where your time is spent, not just in the actual creation, but the ongoing maintenance, HIPAA compliance, the security,” she said. “You’re essentially building an entirely new company on it.”
The regulatory half of that is concrete and getting more so. Any system that stores or transmits electronic protected health information falls under the HIPAA Security Rule, which is indifferent to whether the software was licensed or written in-house. What changes with a purchase is not the obligation but the division of labor: a vendor operating under a business associate agreement carries part of the load, publishes its security posture, and can be asked for it in writing. A tool built internally has no counterparty to ask.
That division of labor may get more expensive to shoulder alone. The Office for Civil Rights published a Notice of Proposed Rulemaking on January 6, 2025 that would remove the longstanding “addressable” flexibility from most Security Rule specifications, making encryption of electronic protected health information at rest and in transit mandatory, along with multifactor authentication, network segmentation, annual penetration testing, and a technology asset inventory and network map refreshed at least every twelve months. The comment period closed in March 2025 and drew more than 4,700 comments, and a coalition of more than 100 hospital systems and provider associations has asked the Department to withdraw it, citing cost and prescriptiveness. The Office for Civil Rights estimated roughly $9 billion in first-year industry compliance cost, and organizations would have about 240 days from publication to comply. It remains a proposal: the Office of Management and Budget’s timetable now points to July 2027 for final action, pushed back from a spring 2026 target, and the rule could still be narrowed or dropped.
Operators should not read the delay as a reprieve. The asset inventory requirement is the one that bears directly on a build decision, because an organization cannot inventory what it does not know it has, and internal tools are the classic thing that never makes the list. That burden falls hardest where there is no compliance department to absorb it, which is the same asymmetry that makes small practice closures leave almost no public record.
AI Code Security Data Shows Speed Improved and Safety Did Not
The other half of Kurth’s objection is quieter and better documented than most operators realize. The productivity gain from AI-assisted development is real but narrower than the marketing suggests, and the security gain has not arrived at all.
Veracode, an application security firm with a commercial interest in the answer that published its methodology anyway, has run the same test since 2025: give more than 100 large language models a battery of coding tasks that can each be completed securely or insecurely, then scan the output. Its 2025 GenAI Code Security Report found models choosing the insecure path in 45 percent of cases. Its spring 2026 update found the more useful pattern: syntax pass rates have climbed from roughly 50 percent to about 95 percent since 2023, while security pass rates have stayed essentially flat, between 45 and 55 percent across model generations and sizes. The tools got dramatically better at producing code that runs. They did not get better at producing code that is safe.
On raw speed the evidence is unsettled. A randomized controlled trial from the nonprofit research group METR found in July 2025 that experienced developers working in codebases they knew well took 19 percent longer with AI tools than without, while believing the tools had made them faster. METR has since said it is revising the experiment design because follow-up data proved too noisy to read, so the result is a snapshot rather than a verdict. What both lines of evidence share is a warning about self-report: the perception of speed is not a measurement of speed, and neither is a measurement of risk.
Questions ABA Operators Should Answer Before Building Software In-House
Kurth’s practical advice inverts the usual sequence. Most operators start from the tool and work backward to a justification. Her example of an implementation that went well was a two-state provider whose non-clinical owner arrived with one defined problem rather than a feature list, and configured only what solved it. “If you’re just looking for technology because you think you’re supposed to have X product in your practice,” she said, “you now have a tool. You don’t really know what you’re doing with it.”
The same discipline applies to building, and it produces a short set of questions an operator can answer before spending anything. What is the specific problem, stated as an outcome rather than a capability? Who maintains this in eighteen months, when the person who built it has been promoted or has left? Does it touch protected health information, and if so, does it appear on the security asset inventory? What happens if it stops working on a Tuesday?
None of that argues for buying. Vendor risk has its own shape in this market, and ABA operators have been reminded of it recently: providers who standardized on one automation vendor were given roughly 90 days to replace it when Thoughtful AI wound down, a decision made two governance levels above any customer relationship. Analytics and outcome tools routinely underperform here because the question of what ABA should measure is itself unsettled, and buyers frequently never meet anyone from the vendor other than a salesperson, which is why knowing who actually builds these products is a reasonable cross-check. Buying transfers some risk and creates other risk.
Kurth’s last point argues against the instinct the question came from. Waiting for the market to settle is itself a decision with a cost. “If you’re sitting there waiting, maybe you give it one month, two months, three months to see what will change,” she said. “You’ve lost three months now of the opportunity to find something that’s going to solve the problems that you’re looking for.” In a sector where the operational mistakes that break multi-site growth tend to be the ones nobody priced, three months of deliberate inaction is a real number on a real income statement. The question is not whether an operator can build. It is what she is prepared to own once she has.
