Behavioral Health Facility Software: Build or Buy at Your Payer Count
The line here is payer count, not bed count. Run one site under about 40 beds with one or two levels of care and three payers and you should buy Kipu, Alleva or Ritten and stop reading.
On this page
The line here is payer count, not bed count. Run one site under about 40 beds with one or two levels of care and three payers and you should buy Kipu, Alleva or Ritten and stop reading. Once you operate multiple licences and more than six payers, the authorization calendar becomes a full time role and the honest answer is neither pure buy nor pure build: keep the electronic health record (EHR) for the chart and build the operational layer on top, which runs $60,000 to $130,000 for a first release in 12 to 16 weeks. Most multi site operators are past the buy line and nowhere near needing to replace their chart.
When is off the shelf genuinely the right call here?
Buy, and build nothing, if you run a single site under about 40 beds with one or two levels of care and three payers. Kipu, Alleva and Ritten will hold the chart, the notes and the billing perfectly adequately at that scale. Sunwave, BestNotes and Lightning Step cover similar ground with different emphases, and for larger clinical enterprises Netsmart myAvatar and Qualifacts CareLogic are the usual candidates. At three payers the authorization calendar fits inside one person's head and a spreadsheet, and every dollar spent on engineering is a dollar not spent on a strong utilization review (UR) nurse and an admissions rep who answers the phone at 11pm. Those two hires will do more for your census than any software will.
Two more situations where buying is right regardless of size. The first is when the real problem is that staff do not update the system. A custom bed board nobody taps is exactly as stale as the whiteboard it replaced, and software does not create discipline. The second is when you are inside a survey window. Introducing new operational systems in the weeks before a Joint Commission or CARF visit adds risk and returns nothing, so wait until the visit is behind you and revisit then.
The strongest argument for buying is that the packaged products are good at the expensive part. A clinical chart a surveyor will accept, an electronic medication administration record, prescribing through Surescripts or DrFirst, and a billing engine that already knows your payers are all mature capabilities, and none of them is where you compete. Rebuilding the chart is the most costly and least differentiating decision available to you in this category, and we talk operators out of it regularly.
When does a custom build actually pay off?
The build case is arithmetic, and it is arithmetic you can run this week from your own numbers. If residential bills at $900 a day and eight clients a month drift two days past an expired authorization before anyone catches it, that is $14,400 written off every month on care your clinicians already delivered. Add the beds you left empty because your census number was stale and an admissions coordinator turned away a referral you actually had room for. Most operators cannot measure that second number precisely, which is exactly why it keeps happening.
Against those two numbers, put the hours your team spends reconciling the census, the customer relationship management (CRM) record and the billing ledger, priced at loaded salary. On a 120 bed operator with nine payers, those three lines together are usually larger than a $120,000 first release, which is why the first phase tends to clear inside one to two quarters. If they are not larger, that is a genuine signal to stay on the packaged product and spend the money on staffing instead.
The qualitative signals matter as much as the money. You have more than one person whose actual job is moving data between systems. Your census, your CRM and your billing disagree and reconciling them is a standing meeting. You bought a second and third facility and discovered your EHR thinks per facility while you now think per organization. Authorization write offs have their own line in the monthly review. Your competitive advantage is a workflow, say taking a detox admission in 90 minutes, and the software is what slows it down. Or the vendor's answer to your single biggest request has been next quarter for four quarters running. Two or more of those, and the case is real.
How do they compare on the things that matter in this industry?
Judge the comparison on things a practitioner can verify, not on feature lists.
- Bed state. Packaged census views are a report over the chart, and the chart updates on clinical timelines. There is no bed object with states, no hold with an expiry, no pending admit, no acuity or gender constraint on which bed a specific referral can occupy. A custom layer makes the bed a first class object updated at the moment something happens rather than at chart closure.
- Authorization structure. The UR module in most behavioral health systems is a text box and a date field. It records that a review happened. It does not hold units remaining, review cadence per payer per level of care, the last reviewer, or an escalation clock. That gap is where the write offs come from.
- Multi entity reach. Four licences under three tax identification numbers with separate provider numbers is a permission and reporting model, not a settings screen. Packaged reporting is generally per facility, and the aggregation you need lives in a spreadsheet somebody rebuilds monthly.
- Consent enforcement. Under 42 CFR Part 2, consent is a scanned document in most systems, and a document cannot enforce anything. Nothing stops a report including a protected client because the system does not know what the consent says.
- Data portability. Getting history out of an incumbent EHR is a structured export rather than a friendly interface, and clinical records carry retention obligations you cannot shortcut. Ask about export format and history depth before you sign anything, not after.
What does total cost of ownership look like at your scale?
A focused first release covering the cross entity bed board, the authorization ledger with escalation and admissions capture wired to your existing EHR runs $60,000 to $130,000 and ships in 12 to 16 weeks in Digital Heroes delivery experience. A full platform adding payer portal work, Part 2 consent enforcement across every outbound path, documentation intelligence, state reporting and analytics runs $150,000 to $400,000 phased over 6 to 12 months.
Payer count moves that number more than bed count does. Once the ledger exists, each additional payer costs roughly $2,000 to $5,000, because each one brings its own review cadence, packet expectations and portal. A 40 bed facility with twelve payers is a more expensive build than a 200 bed facility with four. Part 2 segmentation treated as a phase two item is typically $25,000 to $60,000 and considerably more as a retrofit, because retrofitting it means rebuilding your data layer.
Running costs are where behavioral health differs from ordinary business software. Compliant hosting with a business associate agreement, encryption and audit logging sits at $500 to $1,500 a month for an operator of this size. Support and enhancement runs 15 to 20 percent of build cost a year, and an unusually large share of it goes to payer change rather than new features. Out of hours cover is a real line because a nurse needs the medication record at 3am. And somebody internal has to own the payer rule set, which in practice is a few hours a month from your UR lead. If nobody owns it, the escalation clock starts firing against stale cadences and staff learn to ignore it, which is worse than having no clock at all.
What does the hybrid look like, and when is it the honest answer?
For almost every multi location operator, the hybrid is the answer, and it is worth stating plainly because it is not what most software conversations start with. Keep Kipu or Alleva as the system of record for the chart, the notes and the billing. Build the system of action around it: the bed board across every licence and entity, the authorization ledger with an escalation clock, admissions capture, consent enforcement and analytics. Integrate against the EHR rather than replacing it.
This shape wins on three grounds. It is cheaper, because the chart is the most expensive component and you are not paying for it twice. It ships in months rather than years, because the clinical documentation surface is enormous and the operational surface is not. And it carries no survey risk, because the record a surveyor examines is untouched.
It also changes the financial framing in a way buyers should understand before they model it. You keep paying the subscription. The comparison is therefore not build against buy on licence cost, it is whether the added layer returns more than it costs. Measured against authorization days written off, empty bed nights on beds you were already staffing, and reconciliation hours, it usually does at 120 beds and above.
Which should you choose, by operator size and stage?
One site, under 40 beds, one or two levels of care, three payers: buy. Kipu, Alleva or Ritten, a good UR nurse, and a disciplined census huddle. Revisit when a second facility appears.
Two to three sites, roughly 60 to 120 beds, six to nine payers, one EHR: build the first release layer and keep the chart. Bed board, authorization ledger and admissions, going live unit by unit rather than across all locations on one weekend. Expect $60,000 to $130,000 and 12 to 16 weeks, with the payback resting on write offs and empty bed nights you can already measure.
Multi state, multiple entities, 200 beds or more, twelve or more payers: the same layer, phased into a platform. Sequence consent enforcement and analytics second, payer portal work and state reporting third, ordered by whichever is currently costing you most. Budget $150,000 to $400,000 across 6 to 12 months and do not attempt a single organization wide cutover.
Any size, inside a survey window or mid EHR migration: do nothing new. Finish the thing you are already carrying, then decide.
When you are ready to turn this into a specification, Digital Heroes builds and runs its own products, so the people choosing your architecture live with those decisions on their own revenue. You keep the specification either way.
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) →
- Median SaaS spend reached $9,455 per employee, and organizations leave an average of 36% of their SaaS licenses unused. Source: Zylo (2026) →
- In an RCT, the no-show rate was 23.5% for patients receiving a text-message reminder versus 38.1% for the control group - a 14.6 percentage-point reduction (p = 0.04). Source: Clinical Pediatrics / PubMed Central (Lin et al.) (2016) →
- 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) →
Frequently asked questions
What does it cost to switch off Kipu, and should we?
In most cases you should not switch at all, and that is the cheaper answer as well as the safer one. Keep the incumbent EHR as the record for existing charts, integrate the new operational layer against live data, and migrate only the objects you actually need going forward: beds, authorizations, referrals, payers and consents.
If a full migration is genuinely required, treat it as its own project rather than a line in the build. Plan a structured export, a mapping phase, and a period where both systems stay readable, because clinical retention obligations mean the old system does not simply get switched off.
What happens if our EHR vendor raises prices or changes its pricing model?
This is the argument for building the operational layer rather than depending on the vendor for it. Subscription pricing in this category commonly scales with beds, users or facilities, so growth raises your software cost permanently while a built layer does not. Model your renewal against a three year bed and entity plan rather than against today.
The other protection is portability. If the layer you own holds the bed board, the authorization ledger and the admissions pipeline, an EHR change becomes an integration project instead of a re platforming project, and your bargaining power at renewal improves accordingly.
How long before a first release is actually live in the building?
Twelve to sixteen weeks for something genuinely running on the unit rather than demonstrated in a meeting. That assumes read access to your EHR data, one operational owner on your side who can answer questions within a day, and scope limited to the bed board, the authorization ledger and admissions capture.
Go live unit by unit. The census process is a human habit as much as a system, and the whiteboard has to lose the argument in one building before it loses it everywhere. Payer portal work, Part 2 segmentation across analytics and state reporting extend the programme into the 6 to 12 month range.
Would moving from Kipu to Alleva or Ritten solve this instead?
Sometimes, and it is worth testing before you spend anything on engineering. If your complaint is chart usability, note templates or billing behaviour, a different packaged product may genuinely be a better fit and will cost a fraction of a build.
What a platform change will not fix is the structural gap. None of these products models a bed as an object with states, an authorization with units and a per payer review cadence, or a consent that can be enforced at query time. If those are your failures, you will migrate at considerable disruption and arrive at the same problem under a different logo.
How much does each additional payer add to the build?
Roughly $2,000 to $5,000 each once the authorization ledger exists, because every payer brings its own concurrent review cadence per level of care, its own packet expectations and often its own portal. The first three or four are the expensive ones, since they establish the model.
The practical approach is to build rules for your top six payers by revenue, which covers most of your reviewer workload, and leave the tail on the current manual process until a season of clean data tells you which of them is actually consuming time.
Can a custom system pull authorization status from payer portals automatically?
Only partly, and any developer promising full automation across all your payers has not done this work. Eligibility and some transactions are available through clearinghouses, but concurrent review status for behavioral health levels of care remains largely portal and telephone work.
What a build reliably fixes is the tracking layer: a real authorization record with units, review cadence per payer per level of care, and an escalation clock that creates a task at 72 hours, texts the UR nurse at 48 and the clinical director at 24. That removes the failure mode where three authorizations lapse because one person had the flu.
Does a custom layer help or hurt us with 42 CFR Part 2 and HIPAA?
Built correctly it helps, because consent stops being a scanned document and becomes an enforcement mechanism. Model consent as a live object with data classes, purpose, expiry and revocation, check it at query time on every outbound path, and segment protected clinical detail out of the analytics layer so census, length of stay and revenue can be reported without it.
Then keep an audit log that answers who accessed a record, when, and under what consent in a single query. That is the question a surveyor asks and the question an attorney asks later, and most packaged tools answer it slowly if at all.
Who should own the code and the infrastructure?
You should, completely, from the first commit. The repository, the cloud account, the infrastructure and the data belong to your organization, and that belongs in the contract rather than in a verbal assurance at kickoff.
In a Part 2 environment this is more than a commercial preference. A developer hosting your system in their own account creates a business associate relationship you may not want and a dependency you cannot exit cleanly. If a firm hesitates on ownership, you have learned something useful before spending anything.
Is it cheaper to customize Salesforce than to build a custom CRM from scratch?
If you use less than a third of what Salesforce does, a custom CRM is often cheaper by year three. Salesforce Enterprise lists at $165 per user per month, so 25 seats cost about $49,500 a year before admin and consultant fees, while a focused custom CRM runs $60,000 to $100,000 once plus 15 to 20% a year in maintenance. If you genuinely need Salesforce's ecosystem, reporting, and app marketplace, customizing it beats rebuilding it; the mistake is paying enterprise prices to use it as a glorified contact list.
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.
How many SaaS seats do we need before building custom becomes cheaper?
The crossover usually shows up between 20 and 50 seats on premium tiers. Salesforce Enterprise lists at $165 per user per month, so 40 users cost about $79,000 a year in subscriptions, which is real money against a custom system you would own outright. Run the comparison over three years: if subscription spend beats the build cost plus 15-20% annual maintenance, custom wins on price before you even count workflow fit.
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.
How much should a small business expect to pay for custom software?
Across 2,000+ Digital Heroes projects, a small business system that replaces spreadsheets or one core workflow typically lands between $40,000 and $80,000, with more complex first versions running up to $150,000. The two levers that move the number most are integrations and user roles, not the team's hourly rate. Any quote under $15,000 for a full production system means the vendor has not understood your scope yet.
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.
What is a discovery phase, and is it worth paying for separately?
Pay for it, and treat the output as yours. A discovery phase runs two to three weeks, typically 5 to 10% of the eventual build budget, and produces a written scope, wireframes, and a fixed quote you can take to any vendor, including a competitor of the agency that wrote it. Skipping it is how projects end up quoted from a two-paragraph email and delivered at twice the price.
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.
We run everything on spreadsheets and Airtable. How do we know it's time for custom software?
The reliable signals are re-typing the same data into multiple tools, one employee acting as human middleware between systems, and errors appearing in handoffs between teams. Hard limits force the issue too: Airtable's Team plan caps at 50,000 records per base, and Business costs $45 per seat per month, so a 20-person team pays about $10,800 a year for a tool it has already outgrown. When workarounds consume more hours than the tools save, the spreadsheet era is over.
Does it matter which tech stack the agency wants to use?
Yes, but not in the way most buyers expect: the goal is boring, popular technology such as React, Node.js or Python, and PostgreSQL, because any future team can maintain it and hiring a replacement developer takes days, not months. The red flag is an agency-proprietary framework or an unusual language, which welds you to that one vendor no matter what your contract says about code ownership. A useful test: could you find three freelancers fluent in this stack within a week? If not, push back.
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.
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.
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
More from Eleanor.
VP Client Services · UK & EU · London · 1 post on the site
Published · Last updated .
