Intro: A Sprint Is Cheaper Than a Wrong Year
Most failed custom ABA builds were decided before development started, not during it. Providers often commit to custom software development before confirming whether an existing platform could be configured instead.
They price six payers as one integration line, and misjudge whether EVV applies in their state. Mid-build, they discover assessment integration needs a publisher agreement nobody started. Skipping technician input on custom mobile app development creates a similar kind of gap.
None of these are engineering failures. They are questions with knowable answers. An ABA technology discovery sprint exists to answer them before money moves.
A few weeks of properly scoped discovery cost a small fraction of a build. The result is either a defensible plan or clear evidence that building is not the right move. This article covers what fails without discovery, what a sprint examines, and what it should produce.
What Goes Wrong Without Discovery
Much of what a provider experiences as platform frustration is configuration frustration. Separating the genuinely impossible from the never-attempted is the cheapest work in the project.
Payer complexity gets priced as a single line item. Each managed care organization and commercial payer brings its own authorization process, documentation rules, and unit requirements. An estimate that treats payer configuration as one item understates the real work. That understatement grows close to linearly with payer count.
The EVV assumption fails in either direction. Assuming EVV applies when a state has not extended it to ABA buys unnecessary work. Assuming it does not apply when it does leaves a compliance gap. That gap tends to surface at the worst possible moment.
Assessment licensing gets discovered late, stalling a planned feature behind a negotiation nobody started.
Data capture designed without technician input produces a similar kind of surprise. The people using the app during sessions know where daily friction actually lives. A product built only around clinical leadership demos well and gets resented daily.
Migration gets priced as a task rather than a phase. Historical session data is usually the hardest part to move cleanly.
What a Discovery Sprint Actually Is
A discovery sprint is a short, paid, time-boxed engagement, typically two to four weeks long. It ends in documented findings and a cost recommendation, not a proposal to build.
That separation from the build contract is deliberate. A partner whose discovery fee depends on winning the build has an incentive to recommend building. The engagement should stand alone. Its output should be usable by whichever partner the provider eventually chooses.
Participants on the provider side matter as much as the process. An executive sponsor with real authority needs to be involved, alongside the clinical director. A supervising analyst carrying an actual caseload should join too. So should at least two technicians who deliver sessions daily, plus the scheduling and revenue cycle leads. Those last two spend their day in the office console, so their input shapes the web application development side of the plan as much as technicians shape the capture app.
That last group matters more than it sounds. A sprint that only speaks to leadership produces a plan built on how the organization believes it works.
The output belongs to the provider, not the partner running the sprint. It should be usable in front of a board, a lender, or an alternative vendor.
What the Sprint Examines
Observed Sessions and Real Documentation Time
Watching technicians capture data during actual sessions reveals more than interviews do. Measuring how long documentation genuinely takes afterward matters just as much.
This produces the design requirements for the capture app. It also sets the baseline the project’s benefit case will rest on.
The Payer Inventory
Every funder gets counted, along with its share of volume and authorization process. Documentation expectations, unit and rounding rules, and modifier requirements get logged.
The output recommends which payers get full configuration in release one.
The EVV Determination
For each state of operation, the sprint asks whether EVV applies to in-home ABA there. It also identifies which model that state operates.
If the model is closed, the sprint names the aggregator and onboarding steps. Findings get confirmed with the state Medicaid agency, not inferred.
Documentation, Supervision, and Licensure Scope
The sprint maps which certification and state licensure requirements the platform must carry, across every state of operation.
Supervision documentation and recordkeeping obligations get assessed with counsel wherever the answer is not already clear.
Migration Feasibility and Assessment Licensing
The sprint checks what the incumbent system will release, in what format, and on what terms. Historical session data gets specific attention.
It also checks whether assessment publishers will license integration. Assessment instruments remain licensed intellectual property that a platform cannot simply absorb.
The regulatory scope behind these examinations is covered separately in HIPAA, BACB Ethics Code Documentation, 21st Century Cures Act EVV Mandates and State Autism Insurance Mandates Compliance for US ABA Therapy Software.
What the Sprint Should Produce
A cost comparison of at least three paths belongs at the center of the output. Staying with the current platform is one path.
A hybrid approach, where some capability gets built around an existing system, is another. Full custom development is the third, evaluated on equal footing.
A first-release scope gets defined as one complete workflow, running from scheduled session through captured data to submitted claim. Exclusions get written down so they are not relitigated mid-build.
The payer inventory, EVV determination, and documentation scope should survive the engagement in usable form. A staged budget should show its assumptions openly, so a change in payer or state count can be reasoned about.
A migration plan records what gets fully migrated and what stays as a read-only archive. A technical architecture outline should cover the sync model, authorization engine, and integration approach, enough for a genuine second opinion.
The staged budget this produces is detailed separately in How Much Does Custom ABA Therapy Practice Management Software Cost in the United States? A Complete 2026 Pricing Breakdown.
Reading the Answer: Build, Buy, or Something in Between
Buying makes sense in specific circumstances. An organization in one state with a conventional delivery model often fits existing platforms well. Current products may already carry the needed payer and EVV connections, and capacity for a two-year build may be lacking.
This is the correct answer for a large share of ABA providers. A sprint that never reaches this conclusion for anyone is not run honestly.
Building makes sense once scale changes the math. Per-seat pricing that compounds painfully across many technicians is one signal. Multi-state operation that exceeds what configuration allows is another. So is a data requirement no existing product can express.
This is the ABA software build vs buy question in its clearest form.
Hybrid paths are frequently under-considered by providers weighing the decision. Keeping an existing platform for billing while building the data capture layer is one version. The reverse works too, depending on where friction concentrates.
Replacing only the part causing pain often delivers most of the value, at a fraction of the cost. The sprint’s job is to make that choice with evidence, not conviction.
Red Flags in the Conversation
A fixed build price offered before any discovery is a warning sign. So is discovery offered free and made contingent on winning the build. Payer configuration quoted as a single line item deserves scrutiny, as does EVV described flatly as a federal mandate.
A partner who never asks which states a provider operates in is missing something basic. Assessment licensing that never comes up is another gap. Migration priced as a round number, with no contact made to the current vendor, should raise questions. So should a partner who never asks to observe a session.
The quietest red flag is the absence of any willingness to say an existing system would work better.
The strongest signal runs the opposite direction. A partner who asks to sit in on sessions with families’ consent stands out. Talking to technicians, and describing their own workarounds back to them, shows real diligence.
Final Thoughts
Providers that run a proper ABA technology discovery sprint before committing tend to avoid the costliest mistakes. Observing real sessions and settling the EVV determination per state pay for themselves.
Confirming what the current system will release, and costing at least three paths, rounds out the picture. Either a build gets de-risked, or a smaller change delivers most of the value. Both outcomes are worth many times what the sprint costs.
Weighing a custom platform against the system run today starts with structured discovery. Session observation, payer inventory, per-state EVV determination, and a cost comparison of the three paths make up that work.
NewAgeSysIT works from discovery findings rather than vendor conviction. Learn more about digital transformation solutions from one of the leading AI software companies in the United States.
This article is educational and strategic, not legal, regulatory, or clinical advice. Qualified healthcare regulatory counsel, the state Medicaid agency, and the relevant licensure board are recommended for specifics.
FAQ
What is an ABA technology discovery sprint?
An ABA technology discovery sprint is a short, structured planning engagement completed before committing to custom practice management software. It examines clinical workflows, technician data capture, scheduling, payer requirements, authorization processes, EVV, integrations, migration, and compliance needs. The goal is to determine whether the provider should build custom software, configure an existing platform, or use a hybrid approach before committing significant development resources.
How long should an ABA software discovery sprint take?
A focused ABA software discovery sprint typically takes about two to four weeks, depending on organizational size, states served, payer complexity, and the number of workflows being evaluated. The sprint should be time-boxed and end with documented findings, architecture recommendations, migration considerations, release priorities, and a defensible budget. It should not become an open-ended consulting engagement without clear deliverables or decision criteria.
What should be evaluated during an ABA software discovery sprint?
Discovery should examine real therapy sessions, documentation time, technician workflows, scheduling, payer rules, authorization units, EVV requirements, state licensure considerations, supervision documentation, billing, integrations, assessment licensing, and data migration. It should also document the provider’s current systems and workarounds. These findings help separate problems that require custom development from issues that could be solved through configuration, integration, or process changes.
Who should participate in an ABA technology discovery sprint?
The discovery team should include an executive sponsor, clinical leadership, a supervising behavior analyst with an active caseload, technicians who deliver sessions, scheduling staff, and revenue-cycle personnel. IT, compliance, and operations leaders may also participate where relevant. Including frontline users is critical because leadership may understand the intended workflow, while technicians and administrative staff can reveal the actual workarounds, delays, and repetitive tasks occurring every day.
Why should technicians be observed before designing ABA data collection software?
Technicians use ABA data collection tools while actively delivering therapy, so their workflow constraints are difficult to understand through leadership interviews alone. Observing real sessions can reveal excessive taps, connectivity problems, duplicate documentation, awkward navigation, and other friction. These findings help designers define faster session capture, offline requirements, synchronization behavior, and interface priorities based on actual clinical workflows rather than assumptions about how sessions are performed.
How should payer complexity be evaluated before building ABA software?
Discovery should inventory each significant payer and document its authorization process, service requirements, unit rules, documentation expectations, modifiers, and billing workflows. Payer complexity should not be treated as one generic integration requirement. Identifying high-volume payers also helps define release priorities. The first version can support the most important payer workflows while lower-volume or unusually complex configurations are scheduled for later phases.
How should EVV requirements be evaluated during ABA software discovery?
EVV should be evaluated separately for every state where the ABA provider operates. Federal EVV requirements apply to specified Medicaid personal care and home health services involving in-home visits, but individual states determine how their programs are implemented. Discovery should verify whether applicable ABA services require EVV, identify the state’s model or aggregator, and document any onboarding, certification, data exchange, or integration requirements.
What should an ABA software migration assessment include?
A migration assessment should identify what data the current ABA platform can export, available formats, historical data quality, ownership restrictions, and vendor charges or limitations. Client records, authorizations, schedules, documents, billing data, and historical session information may require different migration strategies. Discovery should determine what must move into the new system and what can remain available through a secure read-only archive after implementation.
