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 gets covered separately in this article.
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 here:
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.
