We've reached a strange moment in software. You can build an application in an afternoon that would have taken an engineering team three months just a few years ago. That's extraordinary progress. It's also created a dangerous misunderstanding about what it actually means to build software.
If you’ve spent years working around ABA software that doesn’t match how your practice actually runs, the idea of building exactly what you need is difficult to resist.
Getting something to work is genuinely fast nowadays. But what happens after you build your own ABA tool? Keeping it clinically accurate, HIPAA-compliant, tested against the edge cases real sessions will surface, and maintaining it as regulations change requires specialized expertise across multiple disciplines. That’s where most homegrown tools run into trouble.
A working demo is not a working product
A dashboard loading, a button saving a session, or a graph showing the number you expected doesn’t prove the software is accurate.
Software has an unfortunate habit of appearing perfectly functional right up until the moment it isn't.
Things can go wrong in ways nobody notices from the interface: two people editing a record at once, a connection dropping mid-session, an unexpected data format, or a calculation at the edge of its allowed range. Data can look right on screen and be stored wrong. Permissions can work for one role while exposing sensitive information to another.
In ABA, clinical decisions depend on that data. If a graph misses a session or double-counts trials, a BCBA® can call mastery too early or change a phase based on information that was never accurate.
Those same data problems carry into billing and compliance. If a session is saved under the wrong date or recorded data don’t match the note, those are the discrepancies a payer will find during an audit. With an established platform, there should be QA layers designed to catch that before it reaches your records. With a homegrown tool, that responsibility falls on whoever built it.
AI-assisted coding makes all of this harder to spot. When the tool explains its own code in confident, fluent language, it feels like someone reviewed it, but no one has. Confidence has never been a reliable indicator of correctness. AI has simply made that problem considerably more efficient. If you can’t independently evaluate the architecture, dependencies, data flows, and failure modes, you may be building on assumptions you can’t verify.
Debugging and testing are a discipline
Every working software product has bugs. Good teams expect that and build systems to find them early, limit the damage, and fix them safely.
That takes layers: peer code review, automated tests, integration and performance testing, user-acceptance testing, security assessment, monitoring, and careful releases. Debugging means reproducing a problem, isolating the cause, understanding what else a fix might affect, and confirming the fix didn’t create a new one.
Much of that work belongs to quality assurance professionals, people whose entire job is trying to break the software. They test the paths a real session actually takes: the RBT® who backs out halfway through a program, the note that gets edited after it’s signed, the tablet that loses Wifi mid-trial. BCBAs will recognize the idea. It’s the same reason they check treatment integrity: whoever builds the plan isn’t the best person to confirm it’s working as designed. AI can help write tests, but it can’t tell you which tests are missing.
In ABA, security and compliance are part of the product
Clinical software holds treatment records, signatures, staff credentials, billing data, and personal details about the learners and families you serve. HIPAA compliance requires continuous work: access controls, encryption, audit logs, vendor management, policies, training, incident response, backups, and regular risk assessments.
That extends to every service your tool relies on. If an outside service, including an AI tool, creates, receives, stores, or transmits protected health information on your behalf, you generally need a Business Associate Agreement with that vendor. And threats keep changing. The external libraries and services your tool relies on will release updates, and some of those updates will patch security flaws. If no one is tracking and applying those patches, your tool’s exposure grows over time without anyone noticing.
The standard to aim for is documented evidence that safeguards were designed, implemented, tested, and maintained.
Expert teams use AI too
Experienced engineers, security specialists, quality professionals, product leaders, and clinical experts all use AI tools. They bring judgment: clearer instructions, a quicker eye for weak output, sound architecture, and the confidence to throw generated code away when it’s wrong.
Clinical work runs on judgment the same way. AI-generated code is a lot like a generic treatment plan: it’s built from what usually works, for a learner it has never met. The value a BCBA adds is knowing what this learner, in this setting, actually needs. Software for clinical work needs that same kind of specialized attention.
Reliable clinical technology comes from many disciplines checking each other’s work: the engineer, the security lead, and the clinician each catching what the others can’t see.
Live software still needs someone to keep it working
Software is never finished. Operating systems, browsers, devices, regulations, and integrations all keep changing. A feature that works today can break after an outside service updates its API. Growth can surface performance problems that never showed up with a few users.
Responsible software should cover the full lifecycle: discovery, design, development, validation, deployment, monitoring, maintenance, and eventually retirement. Beyond the code, there’s the human work: configuring workflows, migrating data, training staff, answering questions, troubleshooting, and communicating when something goes wrong.
When you build your own software, you don't just inherit the functionality. You inherit every bug, every security vulnerability, every regulatory change, and every production incident at 2 a.m. Congratulations. You're now in the software business. Before you take it on, consider who will own it in six months, in three years, or after the person who built it moves on. Something I’ve seen across organizations of very different sizes: clinical capacity and operational overhead pull from the same budget of time and energy. Every hour your team spends maintaining a homegrown tool is an hour that isn’t going toward clinical work.
The flexibility you need doesn’t require building from scratch
What’s usually behind the impulse to build your own tools is a need for control over how things work: the ability to design programs, configure workflows, and set up permissions and rules the way your organization actually operates.
Having to bend your clinical judgment to fit a software’s limitations is one of the most common frustrations I hear from ABA teams. And the answer to that gap isn’t necessarily writing your own code. It’s finding a platform that gives your team that level of control, and has the engineering, compliance, QA, and support infrastructure already in place so you don’t have to create or maintain that foundation yourself.
None of this means organizations should stop building their own technology. Quite the opposite. AI is making custom software more accessible than ever, and enterprise ABA organizations should absolutely be exploring what that means for their operations. But there's a difference between building technology that makes your organization better and rebuilding the clinical infrastructure required to keep it running. One creates competitive advantage. The other creates a second business you never intended to operate.
The goal isn't to own more software. It's to have more control over what your software can do.
Motivity lets you shape your workflow without the responsibility of owning the code
In Motivity, BCBAs configure response prompts, phases, transition logic, and mastery criteria the way the learner needs, not the way the platform needs. Scheduling, billing, permissions, and reporting work the same way: set up around what your organization requires.
Your team shapes the workflow, and our engineering, quality, security, and support teams take care of what’s underneath.
As Jenny Saavedra, BCBA and owner at ABA Spectrum Therapy said:
“Every clinic runs differently, looks different, but Motivity will run your way and look your way.”
If you want to see how a platform can adapt to your needs, we can show you.
