AI Made It Cheap to Build. Not Cheap to Run.
Scott Dickson published a piece last month on MissionViewpoint titled The Hidden Cost of Building Your Own Stack in the Age of AI. His central argument: AI has collapsed the cost of writing code, but it hasn’t done anything about the cost of operating it. Providers who confuse the two are in for an expensive lesson.
He’s right. And we see it play out constantly.
Every few weeks, we talk to a practice that went down this road. They hired a developer — or found one who happens to be a family member — and built a custom scheduling tool, or a data collection app, or a billing tracker. The first version worked. It did exactly what they needed. And then the real costs started.
The List of Things That Break
Dickson frames this as “orchestration complexity.” We’d frame it more bluntly: there’s a long list of things that will go wrong, and most practices don’t find out about them until they’re already committed.
HIPAA compliance isn’t a checkbox. It’s not enough to encrypt your database and call it done. HIPAA compliance means business associate agreements with every vendor that touches PHI. It means audit trails that prove who accessed what and when. It means breach notification protocols. It means access controls that enforce the minimum necessary standard. It means annual risk assessments. A solo developer building a custom tool is almost certainly not doing all of this — and the practice is the one holding the liability.
HIPAA-eligible hosting is its own discipline. You can’t just spin up an EC2 instance and store client data on it. AWS doesn’t sign a BAA for every service. You need specific configurations, specific services, specific logging. Backups, disaster recovery, and failover aren’t optional when you’re holding PHI. Getting this right is a full-time infrastructure job. Getting it wrong is a breach notification to HHS.
Every payer rule change is a regression test. ABA billing is not static. Payers change modifier requirements. States change service definitions. CPT codes get updated. Authorization logic shifts. Every one of these changes means your custom system needs to be updated, tested, and deployed without breaking anything else. Dickson’s article calls this “requirements instability.” We call it Tuesday.
It works at 5 clinicians. It breaks at 50. The system your developer built handles your current caseload fine. But what happens when you add a second location? When you have 200 concurrent sessions? When your database has three years of clinical data and your reports take 45 seconds to load? Performance at scale is a fundamentally different problem than performance at prototype scale.
Every integration is a mini-project. Clearinghouses. Payer portals. Payroll systems. Credentialing databases. Calendar sync. Each integration has its own API, its own quirks, its own versioning. Each one needs to be built, tested, monitored, and maintained. And when the clearinghouse changes their API — which they will — your custom integration breaks until someone fixes it.
Security never ends. Every dependency in your stack has a lifecycle. PHP versions, JavaScript packages, database engines, SSL certificates — they all need patches, updates, and vulnerability monitoring. This isn’t a one-time cost. It’s a permanent obligation. And if your one developer moves on, the knowledge of what’s running and how it’s configured walks out the door with them.
The Cost You Don’t See on the Invoice
The items above are tangible. You can point at them. But the biggest cost is the one Dickson captures perfectly:
“The technology becomes the work — not the enabler of it.”
This is the part that kills practices slowly. Your operations director is now debugging server issues instead of improving workflows. Your BCBA clinical director is testing a new form layout instead of reviewing treatment plans. Your practice owner is negotiating with a freelance developer instead of growing the business.
Every hour spent maintaining custom technology is an hour not spent on care delivery, staff development, or practice growth. The org chart didn’t change, but everyone’s job did. Your ops leader is now an accidental CTO.
Dickson puts it another way: “Autism providers are care organizations first.” We agree. And care organizations should be spending their energy on care.
What “AI Built In” Actually Means
Here’s where our perspective diverges from a pure “don’t build” argument. The answer isn’t just “buy software instead of building it.” The answer is to use a platform where AI is already woven through the workflows you use every day — not bolted on as an afterthought, and not something you have to build yourself.
This is what we’ve been building at StreamABA.
AI-powered session notes (coming soon). Your clinicians collect data during sessions — trial counts, frequency data, duration data, caregiver observations. AI session note drafting, on our roadmap, will synthesize all of it — the client’s diagnoses, goals, session metrics, and clinical context — into professional, insurance-ready documentation in seconds. Not a generic template. A note that reflects what actually happened in that specific session, written at a BCBA documentation standard.
AI insurance card parsing. A parent uploads a photo of their insurance card during intake. Our AI reads the image and extracts the payer name, member ID, group number, plan details, and effective date — automatically populating the fields your staff would otherwise type manually. It works on the public intake form and inside your admin panel.
Practice-level AI configuration. Every practice is different. You can enable or disable AI features, choose the underlying model, adjust the temperature for more or less creative outputs, and even write a custom system prompt that reflects your practice’s documentation style and clinical philosophy. This isn’t a one-size-fits-all AI feature. It’s infrastructure that adapts to how you work.
The Question Every Ops Leader Should Ask
If you’re evaluating whether to build custom technology — or if you already have and you’re feeling the weight of it — ask yourself one question:
Is maintaining this technology making your practice better at delivering care?
If the honest answer is no, then the technology isn’t serving its purpose. It’s consuming the attention and resources that should be going toward the thing your practice actually exists to do.
You don’t need to become a technology company to benefit from technology. You need a platform built by people who already solved the HIPAA compliance, the hosting, the payer integrations, the performance scaling, and the security monitoring — and who are building AI into the product so you don’t have to build it yourself.
That’s what we’re doing. And we think it’s a better use of everyone’s time.
Want to see what purpose-built ABA technology looks like? Reach out at [email protected] — we’ll show you.