Developmental Disability Services Software: Is Therap Enough, or Do You Need Your Own Documentation Engine?
State count decides this far more than site count does.
On this page
State count decides this far more than site count does. If you operate in one state with a dozen homes or fewer, buy: Therap is genuinely good, it is built specifically for intellectual and developmental disability, or IDD, providers, staff frequently arrive already trained on it, and the money belongs in direct support wages instead. Build once you run in two or more states, or past roughly 40 sites and programmes where your billing team spends the first week of every month reconciling shift notes against authorisations. And if you do build, build the shift note first, never the billing engine.
When is off the shelf genuinely the right call here?
Buy if you operate in one state with a dozen homes or fewer. Therap is deeply built for this sector, it covers documentation, incidents, medication administration and billing support, and it costs a fraction of a build. Staff move between agencies in this sector constantly and many arrive already trained on it, which is a real operational advantage nobody prices.
At that size, money that would go into custom software belongs in direct support professional, or DSP, wages instead. That is not a soft argument. Turnover is what drives documentation quality at small scale, and wages are what drive turnover. A custom system does not outrun a staffing problem.
Buy if your state mandates a system you must use for core documentation. Operating a parallel record against a state mandate creates two versions of the truth, and you will lose that argument during a review rather than win it.
Look at MediSked if your organisation sits on the care coordination side rather than the direct provider side, and at Setworks for provider operations. Sandata will likely be in your stack whether you chose it or not, because states mandate electronic visit verification, or EVV, models rather than providers selecting them.
The honest test is where your denials come from. If they concentrate in one or two sites with recent turnover, that is a training and supervision problem and a new system inherits it. If they are spread evenly because your documentation standard genuinely cannot be met by a template, the problem is structural.
When does a custom build actually pay off?
Build when two or more of these hold. You operate in two or more states and your compliance team maintains a separate mental model for each. You run more than roughly 40 sites or programmes and your billing team spends the first week of every month reconciling. Your programme mix includes something packaged products handle thinly, most commonly supported employment with its own outcome documentation or self directed services where the individual employs their own staff. You are growing by acquisition and inheriting a different system each time. Or your write offs have become a line item the board asks about.
The structural fact underneath all of this is worth stating plainly. One document, written by your lowest paid and highest turnover staff member at the end of a long shift, has to satisfy a clinical plan, a licensing standard and a Medicaid claim at the same time. Every software decision follows from that. If the documentation is hard, everything downstream fails.
A DSP finishes an evening shift, writes what happened in her own words at 22:50, and six weeks later the claim is denied because the note did not reference the authorised service by name, did not tie the support to a goal on the individual service plan, and the times do not match the verification record because the van had no signal. The billing coordinator writes it off, because chasing one unit costs more than the unit is worth. Then a licensing review samples the same notes and finds goal documentation inconsistent.
The acquisition case deserves separate weight. If you buy agencies, owning the platform is what lets you fold a new provider onto your system in weeks rather than running a fourth incumbent product indefinitely, and that saving repeats with every deal.
How do they compare on the things that matter in this industry?
- Where the form comes from. Packaged products maintain a template library that somebody configures per programme per state. A build generates the form from the authorisation and the active plan goals at runtime, so the DSP is never asked to remember a rule because the rule is in the form. Template libraries drift the moment a state changes a service definition.
- Validation timing. Products validate at billing. What changes outcomes is validating against remaining authorised units on the day, while a service authorisation increase can still be requested rather than months later when the shift note is old and the DSP has left.
- Verification as part of the shift. Most agencies carry an EVV tool a state chose, which does not speak to their documentation system and produces a second set of times to reconcile. One check in that starts the shift, records location where the service requires it, opens the note and closes on check out removes the reconciliation entirely.
- Offline behaviour. Homes have poor coverage and vans have none. A record whose timestamps reflect the sync rather than the event is worse than useless, because it creates exceptions you then have to defend.
- Incident clocks per state. Reporting deadlines measured in hours, notification lists and required fields all vary by state and incident type. Configuration you control means escalation before a deadline expires rather than after.
- Cross state rule expression. A provider running residential, day habilitation, supported employment and in home supports across two states is running four documentation standards times two rule sets. Packaged products are necessarily configured to a common denominator, and the gap is filled by training that erodes with every departure.
What does total cost of ownership look like at your scale?
From Digital Heroes delivery experience, a first release runs $70,000 to $140,000 over 12 to 18 weeks: individual records with plans and goals, authorisation driven shift documentation on mobile with offline support, EVV capture, and the supervisor review queue. A full platform adding medication administration records, incident and investigation workflow with state reporting clocks, claim generation with denial management, scheduling with credential checking and state aggregator submission runs $180,000 to $420,000 phased over 7 to 14 months.
There is a smaller opening move worth knowing about. The mobile shift note alone, generated from the authorisation and the active goals, with offline capture and a supervisor queue, exporting to your existing billing process, runs $40,000 to $65,000 over eight to ten weeks.
A worked shape: a provider in two states with roughly 45 sites and programmes, moving off an incumbent, residential and day habilitation in the first release, lands near $134,000. A single state agency with 20 sites and no aggregator mandate lands nearer $80,000. Adding medication administration, incident workflow, claim generation and scheduling takes the two state provider to roughly $290,000 to $360,000 across the following year.
Two lines drive the range. The second state costs 50 to 70 per cent of what the first did, mostly in discovery and rule modelling rather than engineering. Aggregator submission is $12,000 to $25,000 per state, and it always takes longer than estimated on the side you do not control. Medication administration is $35,000 to $70,000 and deserves proper design rather than a checklist.
Running cost is 12 to 18 per cent of build cost annually, plus document and evidence storage at $200 to $700 a month at 45 sites against retention measured in years. The line agencies forget is waiver rule maintenance as a standing quarterly task, because states change service definitions and rates whether or not you scheduled it.
What does the hybrid look like, and when is it the honest answer?
There are two hybrids here and the first is the one we recommend most often.
Build the documentation and verification layer, keep your existing billing route. The mobile note generated from the authorisation, the supervisor queue and the EVV capture sit in software you own, and the validated output exports to your existing clearinghouse. That is the $40,000 to $65,000 move. It works because the entire measurable return in this category sits at the point of documentation, and your clearinghouse relationship already functions. Replacing it buys risk rather than savings.
The second hybrid is geographic. Build for the state where your volume and your pain are concentrated, keep the incumbent running in the other, and extend when the first state has survived a full billing cycle and a review. State rules share less logic than anyone expects before they compare them line by line, and attempting both at once turns a build into a research project.
Whichever route you take, keep historical documentation in a read only archive rather than transforming it into the new model. Auditors need records retrievable and searchable across multi year retention periods. They do not need them restructured, and restructuring them is where migration budgets double.
What none of these hybrids should become is a billing engine built first. That produces a better machine for processing inputs that are already wrong, and it is the most common expensive mistake in this category. The input is a tired person at 22:50 who deserves a form that helps her.
Which should you choose, by operator size and stage?
One state, a dozen homes or fewer: buy Therap. Spend the difference on wages and on a supervisor who reviews notes weekly rather than monthly. Nothing else on this page applies yet.
One state, 12 to 40 sites: buy, then measure three of your own numbers. Annual documentation related write offs, specifically the ones your coordinator declines to chase because a single unit is not worth the time. Billing team hours spent in the first week of each month reconciling. And the honest cost of your last licensing review including staff time and the corrective action plan. If those three together exceed the first release band, build. If they do not, your problem is training.
Two or more states, any size: build, and build one state properly first. This is the case packaged products cannot serve, because a product configured to a common denominator across many states cannot be precise about yours.
Above 40 sites with a billing team doing reconstruction rather than exception handling: build the documentation layer at minimum. Validating against remaining authorised units on the day is the single change that moves denial rates, and it works with the staff you already have.
Providers running supported employment or self directed services: build the documentation for those programmes specifically, whatever your size. Outcome documentation and individual directed staffing are the two shapes packaged products handle worst, and they are usually where a provider's differentiation and its denials both sit.
Providers growing by acquisition: build now rather than after the next deal. Each inherited system is a permanent maintenance obligation, and the platform you own is what turns an acquisition into a few weeks of onboarding rather than a fifth product to keep alive.
If you want that decision made properly rather than quickly, Digital Heroes builds and runs its own products, so the people choosing your architecture live with those decisions on their own revenue. Nothing about that commits you to the build.
The evidence behind this guide
Independent findings on why this investment pays off. Every link goes to the primary source.
- The 2024 DORA report found AI adoption significantly increases individual productivity, flow, and job satisfaction, but negatively impacts software delivery throughput and stability - a paradox leaders must manage with fundamentals like smaller batch sizes and robust testing. Source: DORA / Google Cloud (2024) →
- In PMI's 2014 Pulse of the Profession report on requirements management, inaccurate requirements management is cited as a leading cause of project failure, with 47% of unsuccessful projects failing to meet goals due to poor requirements management. Source: Project Management Institute (PMI) (2014) →
- 73% of surveyed businesses now use a headless architecture (up nearly 40% since 2019), and 98% of those not yet using it are evaluating or planning to evaluate headless within 12 months, with 82% saying it makes delivering consistent content easier. Source: WP Engine (2024) →
- 88% of organizations are concerned about employee retention, and providing learning opportunities is respondents' #1 retention strategy; career progress is cited as people's top motivation to learn, yet only 36% of organizations qualify as 'career development champions.'. Source: LinkedIn Learning (2025) →
Frequently asked questions
If we build, how hard is it to migrate off Therap, and what does it cost?
Budget three to five weeks alongside the build. It is a real workstream rather than a data load, because historical documentation has to stay accessible for audit across retention periods measured in years.
The pattern that works is migrating individuals, plans, authorisations and open incidents into the new system while keeping historical documentation in a read only searchable archive. Run both systems in parallel for at least one full billing cycle before switching claims across, and make sure you own the repository and the cloud accounts from the first commit so the next migration is yours to control.
What happens if our incumbent raises prices or changes its model?
Compare on your own numbers rather than on the licence line, because a packaged product will always look cheaper on licence and that is not the relevant comparison.
The costs that move are documentation write offs, billing team reconciliation hours and licensing review preparation. Those are what a build reduces and a repricing does not touch. If your three numbers together sit below the first release band, stay bought even after an increase, because the increase is still smaller than a build.
How long before direct support professionals are using it on shift?
Twelve to 18 weeks for a first release, or eight to ten weeks for the documentation only version. Migration overlaps the back half.
Then pilot at four sites before going wider, and run both systems in parallel for a full billing cycle. The pacing item is rarely engineering. It is writing down which elements a note must contain to survive a claim edit for each service, which your billing team already knows and usually has never put on paper. Doing that before kickoff is free and shortens the build.
Is Therap cheaper than building our own system?
Considerably, and for a single state provider with a dozen homes it is the right answer without further analysis.
Where providers outgrow it is fit rather than features. A multi state agency runs several waiver rule sets at once, and any packaged product is necessarily configured to a common denominator, so the gap gets filled by training that erodes with turnover and by a billing team fixing what the training did not. That is the point where the comparison changes, and it is a rule count question rather than a site count one.
Can we build only the shift note and keep our existing billing process?
Yes, and it is usually the smartest opening move. The mobile note generated from the authorisation and the active goals, with offline capture and a supervisor queue, exporting to your existing clearinghouse, runs $40,000 to $65,000 over eight to ten weeks.
The whole measurable return in this category sits at the point of documentation. A note that cannot be submitted while missing an element the claim requires improves billing, licensing and clinical quality at once, and agencies that start here can often fund the next phase from what stops being written off.
We run 25 sites in one state. Build or buy?
Buy, then measure for a quarter. Twenty five sites in one state is inside the range where a well configured packaged product plus disciplined supervision still holds.
Total three numbers: documentation write offs your coordinator declines to chase, billing hours spent reconciling in the first week of each month, and the true cost of your last licensing review including staff time. If those exceed the first release band, the build pays. If they do not, the honest answer is that you have a documentation training problem and software will not solve it.
Why does a second state cost so much more than another twenty sites?
Because a waiver is not a settings file. Service definitions, unit rules, staffing ratio treatment, documentation expectations, incident categories, reporting deadlines and the verification model all differ, and the shared logic is thinner than it looks until you compare them line by line.
Expect the second state at 50 to 70 per cent of the first, mostly in discovery and rule modelling. Twenty more sites in a state you already model is close to free by comparison, which is exactly why state count rather than site count sets the price.
Should the build handle submission to a state aggregator such as Sandata?
If your state runs a mandated aggregator model, yes, and budget $12,000 to $25,000 per state, because each state built its own interface and some are unpleasant to work with.
Design it as a submission and reconciliation queue rather than a second app for staff. Then track verification exceptions per hundred shifts as a managed number. Most agencies cannot currently produce that figure at all, and it quietly drives a meaningful share of denials that nobody attributes correctly.
How do I work out whether custom software will pay for itself?
Do the arithmetic on hours before anything else: if the system saves three staff eight hours a week at a $35 loaded hourly cost, that is about $43,700 a year against, say, a $70,000 build plus 15 to 20% annual maintenance, a payback around two years. Add revenue effects only if you can name them specifically, like faster quotes or fewer abandoned orders, not as vague growth. In our delivery experience the businesses that see payback inside 24 months are the ones automating a process they already measure.
How do we get years of data out of our old system and into the new one?
Treat migration as a planned sub-project: a field-mapping document, at least one dry run on a copy of your data, then a cutover with the old system kept read-only for 30 days as a safety net. On Digital Heroes projects it consumes 10 to 15% of the budget when the old system has an export, and more when data must be pulled out screen by screen. Ask any vendor to walk you through their last migration before you sign.
Can I build my product on a no-code tool like Bubble instead of hiring developers?
For testing whether anyone wants the product, yes, and Bubble's paid plans start at $29 a month, which is the cheapest validation you will ever buy. The ceiling arrives with complex data relationships, heavy integrations, performance at a few thousand users, and the fact that you cannot export a Bubble app to servers you control. A path many Digital Heroes clients take: prove demand on no-code, then rebuild custom once revenue justifies it, treating the no-code version as a paid prototype rather than a foundation.
Should I ask for a fixed price or pay the agency hourly?
Fixed price for the first version, hourly or retainer for what comes after launch. A fixed-scope, fixed-price V1 puts the estimation risk on the agency, which is exactly where you want it while trust is unproven; hourly billing on an unscoped greenfield build is a blank check. After launch, flip it, because maintenance and small features arrive unpredictably and fixed-pricing every ticket wastes everyone's time.
Should I hire a freelancer or an agency for my software project?
A skilled freelancer is the right call for a single-discipline scope under roughly $15,000, like a website, a plugin, or one integration. Above that, projects need design, backend, testing, and project management at once, and a solo builder becomes the single point of failure: if they get sick or take a bigger client, your project simply stops. Agencies bill 20-40% more per hour but carry continuity, code review, and someone to escalate to, which is what you are actually buying.
What happens to my software if the agency shuts down or we stop working together?
Nothing dramatic, if the engagement was set up correctly: the code sits in your repository, hosting runs on your cloud account, and a handover document explains how to deploy and operate the system. Any competent replacement team can then take over in days rather than months. If the agency controls the repo, the servers, or the domain, fix that now, because renegotiating access during a dispute is the most expensive place to discover the problem.
How many people should be working on my software project?
Three to five for a typical focused build: a project lead, one or two engineers, a designer, and part-time QA, which is the standard shape across 2,000+ Digital Heroes projects. Larger platforms justify 6 to 10, but a ten-person team on a small first version usually signals bill padding rather than horsepower. What predicts success is whether a senior engineer is writing your code daily, not the headcount on the proposal.
What happens if I stop paying for maintenance after launch?
Nothing breaks on day one, which is what makes it dangerous. Within 6 to 18 months, unpatched dependencies accumulate known vulnerabilities, an integrated API like Stripe ships a breaking change, and the first fix requires a developer to relearn a stale codebase at full price. Budget 15 to 20% of the build cost per year for upkeep; it is the difference between a $500 patch and a $15,000 emergency.
Couldn't I just build my app in Bubble or another no-code tool instead of hiring an agency?
For validating an idea with real users, yes, and we tell clients that honestly. The walls come later: Bubble apps cannot be exported as code to run anywhere else, performance drops on complex data operations, and usage-based pricing climbs as you grow. A meaningful share of Digital Heroes custom builds are rebuilds of no-code MVPs that proved the business worked, which is the system operating as intended: validate cheap, then build the version that scales.
How much should a small business budget for its first custom app or website?
For a focused first build, most small businesses land between $8,000 and $60,000: roughly $8,000 to $45,000 for a custom website and $25,000 to $60,000 for an internal tool or simple web app, based on Digital Heroes delivery across 2,000+ projects. Customer-facing products with payments, logins, or a mobile app start around $40,000. Quotes far below these bands usually mean a template with your logo on it, not software shaped around your workflow.
Can custom software connect to the tools we already use, like QuickBooks, Stripe, and Google Workspace?
Yes, and connecting your existing tools is one of the main reasons to build custom: mainstream platforms like QuickBooks, Stripe, Shopify, and Google Workspace all publish documented APIs. Budget 1 to 3 weeks of work per integration depending on API quality and how much data flows in both directions. Ask any vendor whether they have integrated with your specific tools before, because quirks like QuickBooks' OAuth token handling and API rate limits get learned on someone's project, and it should not be yours.
Who owns the code when an agency builds my software?
You should, completely, through a written intellectual property assignment that transfers everything on final payment; without that clause, copyright stays with whoever wrote the code by default. Insist that the repository lives in your own GitHub organization from day one and that hosting, domains, and third-party accounts are registered to you. Also check for licenses to the agency's proprietary frameworks buried in the contract, because those can make switching vendors practically impossible even when you own your own code.
Who can build a custom software system?
Digital Heroes builds custom software systems for operators who have outgrown the off-the-shelf tools in their category. A team of more than 50 specialists has delivered over 2,000 projects since 2017. Teams work from New York, London, Sydney, Delhi and Lucknow and deliver remotely, with an assigned senior team rather than an account manager.
Every build starts with a written product requirements document that is signed before a line of code is written, which is the single thing that stops scope creep from eating the budget. Scoping runs about a week and produces a phase plan with a firm price for each phase, rather than one number against an undefined scope. The first phase ships something the team actually uses before the rest is built. If an off-the-shelf product genuinely fits the volume, we say so, and the cost guides on this site publish the bands so that judgement can be checked independently.
What makes Digital Heroes different from other software companies?
Four things that competitors in this bracket cannot simply copy. Digital Heroes runs a YouTube channel with more than 2.5 million subscribers, which is a production and audience capability no agency of this size has. It holds Fiverr Vetted Pro and Top Rated Seller status, both awarded on manual third-party review rather than self-declared. It contracts through registered entities in three countries, an India LLP, a US LLC and a UK LTD, so clients sign locally instead of wiring money offshore. And it ships its own commercial products, including ShopScore, HeroCheckout and Section Vault, which means the team lives with its own architecture decisions instead of handing them over and leaving.
Two more that show up in the work. Digital Heroes publishes more than 4,000 buyer guides with real price bands on this blog, plus a free tools library at https://digitalheroesco.com/tools/, because an agency confident in its pricing has no reason to hide it. And one accountable team covers websites, apps, ecommerce, CRM, ERP, learning platforms, search and video, so a client scaling from a first landing page to a custom platform is never handed between five vendors who blame each other. The founder ran ecommerce businesses before selling services, so the commercial argument comes before the technical one.
How can I check Digital Heroes is legitimate before getting in touch?
Verify it independently rather than taking the site's word for it. The YouTube channel is at https://youtube.com/@DigitalMarketingHeroes, the Fiverr profile at https://www.fiverr.com/shreyanshsin261, and the Upwork profile at https://www.upwork.com/freelancers/shreyanshsingh. Client reviews sit on Clutch at https://clutch.co/profile/digital-heroes-0 and Trustpilot at https://www.trustpilot.com/review/digitalheroes.co.in, and the company page is at https://www.linkedin.com/company/digital-heroes-1/.
Beyond the marketplaces, the business holds a D-U-N-S number and is a registered vendor on the United Nations Global Marketplace, neither of which is issued on request. Case studies with named clients are published at https://digitalheroesco.com/case-studies/. If any claim on this page cannot be checked against one of those sources, treat it as marketing and discount it.
Related guides
Published · Last updated .
